aboutsummaryrefslogtreecommitdiffstats
path: root/fs/9p/vfs_super.c
diff options
context:
space:
mode:
authorMichel Lespinasse <walken@google.com>2012-03-26 17:32:44 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2012-03-28 09:54:34 -0700
commitb18dafc86bb879d2f38a1743985d7ceb283c2f4d (patch)
tree447070f77406615aebadaef03018d634c0da922c /fs/9p/vfs_super.c
parent6658a6991cef75719a21441aa0b7f8d6821534ee (diff)
downloadkernel_goldelico_gta04-b18dafc86bb879d2f38a1743985d7ceb283c2f4d.zip
kernel_goldelico_gta04-b18dafc86bb879d2f38a1743985d7ceb283c2f4d.tar.gz
kernel_goldelico_gta04-b18dafc86bb879d2f38a1743985d7ceb283c2f4d.tar.bz2
vfs: fix d_ancestor() case in d_materialize_unique
In d_materialise_unique() there are 3 subcases to the 'aliased dentry' case; in two subcases the inode i_lock is properly released but this does not occur in the -ELOOP subcase. This seems to have been introduced by commit 1836750115f2 ("fix loop checks in d_materialise_unique()"). Signed-off-by: Michel Lespinasse <walken@google.com> Cc: stable@vger.kernel.org # v3.0+ [ Added a comment, and moved the unlock to where we generate the -ELOOP, which seems to be more natural. You probably can't actually trigger this without a buggy network file server - d_materialize_unique() is for finding aliases on non-local filesystems, and the d_ancestor() case is for a hardlinked directory loop. But we should be robust in the case of such buggy servers anyway. ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/9p/vfs_super.c')
0 files changed, 0 insertions, 0 deletions