I'm getting a sneaky race condition failure since this commit (after
painstakingly bisecting it through the day):
commit 4bf46a272647d89e780126b52eda04737defd9f4
Author: David Howells <dhowells@xxxxxxxxxx>
Date: Thu Mar 5 14:09:22 2015 +0000
VFS: Impose ordering on accesses of d_inode and d_flags
Impose ordering on accesses of d_inode and d_flags to avoid the need
to do this:
if (!dentry->d_inode || d_is_negative(dentry)) {
when this:
if (d_is_negative(dentry)) {
should suffice.
This check is especially problematic if a dentry can have its type
field set to something other than DENTRY_MISS_TYPE when d_inode is
NULL (as in unionmount).
What we really need to do is stick a write barrier between setting
d_inode and setting d_flags and a read barrier between reading
d_flags and reading d_inode.
Test run:
make -j17 on a kernel over 9P/RDMA (nfs-ganesha serving a tmpfs
directory)
This patch has nothing 9p specific so I'll try to reproduce with virtio
or another filesystem tomorrow. I think 9P hits this more easily because
the lack of cache makes it create and delete inodes alot...
I tried to make a reproducer but couldn't come up with anything, usually
open()/read()/close() like mad gets me similar bugs but that didn't work
out this time; it might be missing some fiddling with directories.
Error:
mostly this message during the build:
"fixdep: error opening config file: arch/x86/include/uapi/asm/ioctl.h:
Not a directory"
sometimes I get ENOENT but I get ENOTDIR 4 times out of 5.
Header file varies, but the whole build rarely passes (defconfig)
I managed to reproduce while dumping pcap of the build and did not see
any ENOTDIR over the wire, so assuming the race condition happens in the
kernel... Which I'm pretty confident about after bisecting the client
(and changing the server didn't help)
Soo. The barriers do look right, I'm not quite sure what it could be.
A co-worker pointed out that __d_set_inode_and_type clears d_flags for
DCACHE_ENTRY_TYPE and DCACHE_FALLTHRU, and __d_obtain_alias didn't clear
these before, but I still get the same error if I don't (although it did
seem longer to reproduce).
I have no idea what __d_obtain_alias does or if it's ok if it clears it,
just saying I tried.
My guess is that I'm just seeing a race condition that already existed
but the barriers make it easier to reproduce it.
This commit came with 2b0143b5c9 "VFS: normal filesystems (and lustre):
d_inode() annotations" which made 9P access d_inode through the helper,
which could have helped with ordering, but I'm still hitting the bug
"easily" with that commit.
Any idea? Anything I could test to help diagnose this?
Thanks,
--
Dominique Martinet
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
