diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2012-05-21 16:14:04 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2012-05-21 16:14:04 -0700 |
commit | 6326c71fd2fb3bef5fa33951479298b683da35fe (patch) | |
tree | 6bccc510bc127380439d2ac922fea5ec3ec6927d /kernel/panic.c | |
parent | a70b52ec1aaeaf60f4739edb1b422827cb6f3893 (diff) | |
download | linux-6326c71fd2fb3bef5fa33951479298b683da35fe.tar.gz linux-6326c71fd2fb3bef5fa33951479298b683da35fe.tar.bz2 linux-6326c71fd2fb3bef5fa33951479298b683da35fe.zip |
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>
Diffstat (limited to 'kernel/panic.c')
0 files changed, 0 insertions, 0 deletions