summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/syscall-counts.py
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2014-03-20 15:18:22 -0400
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2014-04-03 12:02:34 -0700
commit7ce510b1e42d51dfbf2e184778039a34dbba6131 (patch)
treec4a9b2750b2654a7f48e583ae2ee2b51d8e013f6 /tools/perf/scripts/python/syscall-counts.py
parentda49d7d6349af87e838f881f593337c9459d883a (diff)
rcuwalk: recheck mount_lock after mountpoint crossing attempts
commit b37199e626b31e1175fb06764c5d1d687723aac2 upstream. 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. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/perf/scripts/python/syscall-counts.py')
0 files changed, 0 insertions, 0 deletions