]> git.baikalelectronics.ru Git - kernel.git/commit
vfs: be even more careful about dentry RCU name lookups
authorLinus Torvalds <torvalds@linux-foundation.org>
Mon, 21 May 2012 23:14:04 +0000 (16:14 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Mon, 21 May 2012 23:14:04 +0000 (16:14 -0700)
commitaa20d89fb4ad8222cc1a18f227ea0df963daa09e
tree6bccc510bc127380439d2ac922fea5ec3ec6927d
parentba20caa268f6086f6144df278af20f0496145875
vfs: be even more careful about dentry RCU name lookups

Miklos Szeredi points out that we need to also worry about memory
odering when doing the dentry name comparison asynchronously with RCU.

In particular, doing a rename can do a memcpy() of one dentry name over
another, and we want to make sure that any unlocked reader will always
see the proper terminating NUL character, so that it won't ever run off
the allocation.

Rather than having to be extra careful with the name copy or at lookup
time for each character, this resolves the issue by making sure that all
names that are inlined in the dentry always have a NUL character at the
end of the name allocation.  If we do that at dentry allocation time, we
know that no future name copy will ever change that final NUL to
anything else, so there are no memory ordering issues.

So even if a concurrent rename ends up overwriting the NUL character
that terminates the original name, we always know that there is one
final NUL at the end, and there is no worry about the lockless RCU
lookup traversing the name too far.

The out-of-line allocations are never copied over, so we can just make
sure that we write the name (with terminating NULL) and do a write
barrier before we expose the name to anything else by setting it in the
dentry.

Reported-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Nick Piggin <npiggin@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/dcache.c