On Sun, May 5, 2019 at 4:47 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Sun, May 05, 2019 at 04:19:02PM +0300, Amir Goldstein wrote: > > > I have made an analysis of callers to d_delete() and found that all callers > > either hold parent inode lock or name is stable for another reason: > > https://lore.kernel.org/linux-fsdevel/20190104090357.GD22409@xxxxxxxxxxxxxx/ > > > > But Jan preferred to keep take_dentry_name_snapshot() to be safe. > > I think the right thing to do is assert that parent inode is locked or > > no rename op in d_delete() and take the lock in ceph/ocfs2 to conform > > to the standard. > > Any messing with the locking in ceph_fill_trace() would have to come > with very detailed proof of correctness, convincingly stable wrt > future changes in ceph... Yeh... Is there any other way to assert that d_name is stable in d_delete()? My original rule was: WARN_ON_ONCE(!inode_is_locked(dir) && dir->i_op->rename && !(dir->i_sb->s_type->fs_flags & FS_RENAME_DOES_D_MOVE)); In the hope that declaring FS_RENAME_DOES_D_MOVE means fs knows what it is doing... Thanks, Amir.
