summaryrefslogtreecommitdiff
path: root/fs/namei.c
diff options
context:
space:
mode:
authorMiklos Szeredi <mszeredi@suse.cz>2011-05-25 00:06:10 +0400
committerAl Viro <viro@zeniv.linux.org.uk>2011-05-26 15:26:50 +0400
commitb5afd2c406f5c6272d916fd705f44f070fbbc0ba (patch)
tree93378abaf5120d5fe449ee77234368291331615a /fs/namei.c
parent5c5d3f3b871a719e2c6413b85009c723adeb27e1 (diff)
downloadlinux-b5afd2c406f5c6272d916fd705f44f070fbbc0ba.tar.xz
vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems
vfs_rename_dir() doesn't properly account for filesystems with FS_RENAME_DOES_D_MOVE. If new_dentry has a target inode attached, it unhashes the new_dentry prior to the rename() iop and rehashes it after, but doesn't account for the possibility that rename() may have swapped {old,new}_dentry. For FS_RENAME_DOES_D_MOVE filesystems, it rehashes new_dentry (now the old renamed-from name, which d_move() expected to go away), such that a subsequent lookup will find it. Currently all FS_RENAME_DOES_D_MOVE filesystems compensate for this by failing in d_revalidate. The bug was introduced by: commit 349457ccf2592c14bdf13b6706170ae2e94931b1 "[PATCH] Allow file systems to manually d_move() inside of ->rename()" Fix by not rehashing the new dentry. Rehashing used to be needed by d_move() but isn't anymore. Reported-by: Sage Weil <sage@newdream.net> Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/namei.c')
-rw-r--r--fs/namei.c2
1 files changed, 0 insertions, 2 deletions
diff --git a/fs/namei.c b/fs/namei.c
index 4c5cbd5371a3..a1593baec0bd 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2989,8 +2989,6 @@ static int vfs_rename_dir(struct inode *old_dir, struct dentry *old_dentry,
dont_mount(new_dentry);
}
mutex_unlock(&target->i_mutex);
- if (d_unhashed(new_dentry))
- d_rehash(new_dentry);
}
if (!error)
if (!(old_dir->i_sb->s_type->fs_flags & FS_RENAME_DOES_D_MOVE))