diff options
author | Al Viro <viro@zeniv.linux.org.uk> | 2014-03-20 15:18:22 -0400 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2014-03-23 00:32:55 -0400 |
commit | b37199e626b31e1175fb06764c5d1d687723aac2 (patch) | |
tree | 0ac51a84f15fa251800fb40191dcf4a86c4c04c2 /fs/jfs/jfs_unicode.h | |
parent | e825196d48d2b89a6ec3a8eff280098d2a78207e (diff) | |
download | linux-stable-b37199e626b31e1175fb06764c5d1d687723aac2.tar.gz linux-stable-b37199e626b31e1175fb06764c5d1d687723aac2.tar.bz2 linux-stable-b37199e626b31e1175fb06764c5d1d687723aac2.zip |
rcuwalk: recheck mount_lock after mountpoint crossing attempts
We can get false negative from __lookup_mnt() if an unrelated vfsmount
gets moved. In that case legitimize_mnt() is guaranteed to fail,
and we will fall back to non-RCU walk... unless we end up running
into a hard error on a filesystem object we wouldn't have reached
if not for that false negative. IOW, delaying that check until
the end of pathname resolution is wrong - we should recheck right
after we attempt to cross the mountpoint. We don't need to recheck
unless we see d_mountpoint() being true - in that case even if
we have just raced with mount/umount, we can simply go on as if
we'd come at the moment when the sucker wasn't a mountpoint; if we
run into a hard error as the result, it was a legitimate outcome.
__lookup_mnt() returning NULL is different in that respect, since
it might've happened due to operation on completely unrelated
mountpoint.
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/jfs/jfs_unicode.h')
0 files changed, 0 insertions, 0 deletions