diff options
| author | Linus Torvalds | 2012-05-22 03:48:10 +0200 |
|---|---|---|
| committer | Linus Torvalds | 2012-05-22 03:48:10 +0200 |
| commit | 2e321806b681b1920b6dfa7d81bbe3d312fe1d19 (patch) | |
| tree | ba9d8b2e4ac401ef1ce0ac86662af2e032584485 /arch/m68k | |
| parent | Merge tag 'rdma-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/rol... (diff) | |
| download | kernel-qcow2-linux-2e321806b681b1920b6dfa7d81bbe3d312fe1d19.tar.gz kernel-qcow2-linux-2e321806b681b1920b6dfa7d81bbe3d312fe1d19.tar.xz kernel-qcow2-linux-2e321806b681b1920b6dfa7d81bbe3d312fe1d19.zip | |
Revert "vfs: remove unnecessary d_unhashed() check from __d_lookup_rcu"
This reverts commit 8c01a529b861ba97c7d78368e6a5d4d42e946f75.
It turns out the d_unhashed() check isn't unnecessary after all: while
it's true that unhashing will increment the sequence numbers, that does
not necessarily invalidate the RCU lookup, because it might have seen
the dentry pointer (before it got unhashed), but by the time it loaded
the sequence number, it could have seen the *new* sequence number (after
it got unhashed).
End result: we might look up an unhashed dentry that is about to be
freed, with the sequence number never indicating anything bad about it.
So checking that the dentry is still hashed (*after* reading the sequence
number) is indeed the proper fix, and was never unnecessary.
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/m68k')
0 files changed, 0 insertions, 0 deletions