summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJ. Bruce Fields <bfields@redhat.com>2012-05-09 17:18:05 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2012-05-30 21:04:54 -0400
commit7732a557b1342c6e6966efb5f07effcf99f56167 (patch)
treed947f3aa85c11e426f48509ec52f351a74815cb9
parent244ca2b4d0b5e500681e52ad9e6d7f3f2b9362a1 (diff)
downloadlinux-3.10-7732a557b1342c6e6966efb5f07effcf99f56167.tar.gz
linux-3.10-7732a557b1342c6e6966efb5f07effcf99f56167.tar.bz2
linux-3.10-7732a557b1342c6e6966efb5f07effcf99f56167.zip
vfs: stop d_splice_alias creating directory aliases
A directory should never have more than one dentry pointing to it. But d_splice_alias() will add one if it finds a directory with an already-existing non-DISCONNECTED dentry. I can't find an obvious reproducer, but I also can't see what prevents d_splice_alias() from encountering such a case. It therefore seems safest to allow d_splice_alias to use any dentry it finds. (Prior to the removal of dentry_unhash() from vfs_rmdir(), around v3.0, this could cause an nfsd deadlock like this: - Somebody attempts to remove a non-empty directory. - The dentry_unhash() in vfs_rmdir() unhashes the dentry pointing to the non-empty directory. - ->rmdir() then fails with -ENOTEMPTY - Before the vfs_rmdir() caller reaches dput(), an nfsd process in rename looks up the directory by filehandle; at the end of that lookup, this dentry is found by d_alloc_anon(), and a reference is taken on it, preventing dput() from removing it. - A regular lookup of the directory calls d_splice_alias(), finds only an unhashed (not a DISCONNECTED) dentry, and insteads adds a new one, so the directory now has two dentries. - The nfsd process in rename, which was previously looking up the source directory of the rename, now looks up the target directory (which is the same), and gets the dentry newly created by the previous lookup. - The rename, seeing two different dentries, assumes this is a cross-directory rename and attempts to take the i_mutex on the directory twice. That reproducer no longer exists, but I don't think there was anything fundamentally incorrect about the vfs_rmdir() behavior there, so I think the real fault was here in d_splice_alias().) Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-rw-r--r--fs/dcache.c3
1 files changed, 1 insertions, 2 deletions
diff --git a/fs/dcache.c b/fs/dcache.c
index 40469044088..3d4be6f8e49 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1650,9 +1650,8 @@ struct dentry *d_splice_alias(struct inode *inode, struct dentry *dentry)
if (inode && S_ISDIR(inode->i_mode)) {
spin_lock(&inode->i_lock);
- new = __d_find_alias(inode, 1);
+ new = __d_find_any_alias(inode);
if (new) {
- BUG_ON(!(new->d_flags & DCACHE_DISCONNECTED));
spin_unlock(&inode->i_lock);
security_d_instantiate(new, inode);
d_move(new, dentry);