[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1KKtlz-0008B9-BM@pomaz-ex.szeredi.hu>
Date: Mon, 21 Jul 2008 13:41:47 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: viro@...IV.linux.org.uk
CC: sage@...dream.net, zach.brown@...cle.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [patch] vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems
From: Miklos Szeredi <mszeredi@...e.cz>
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.
This was caught by the recently posted POSIX fstest suite, rename/10.t
test 62 (and others) on ceph.
Fix by not rehashing the new dentry. Rehashing would only make sense
if the rename failed (which should happen extremely rarely), but we
cannot handle that case correctly 100% of the time anyway, so...
Reported-by: Sage Weil <sage@...dream.net>
CC: Zach Brown <zach.brown@...cle.com>
Signed-off-by: Miklos Szeredi <mszeredi@...e.cz>
---
fs/namei.c | 2 --
1 file changed, 2 deletions(-)
Index: linux-2.6/fs/namei.c
===================================================================
--- linux-2.6.orig/fs/namei.c 2008-07-21 09:46:07.000000000 +0200
+++ linux-2.6/fs/namei.c 2008-07-21 11:56:01.000000000 +0200
@@ -2574,8 +2574,6 @@ static int vfs_rename_dir(struct inode *
if (!error)
target->i_flags |= S_DEAD;
mutex_unlock(&target->i_mutex);
- if (d_unhashed(new_dentry))
- d_rehash(new_dentry);
dput(new_dentry);
}
if (!error)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists