Re: Race condition introduced in 4bf46a27 VFS: Impose ordering on accesses of d_inode and d_flags

[Dominique Martinet <dominique.martinet@cea.fr>]

Dominique Martinet wrote on Thu, Jul 30, 2015 at 01:50:45PM +0200:
> > 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.
> 
> Still looking for ideas to help diagnose further...

Slowly progressing, through carefully placed systemtap probes I got down
to this check in link_path_walk in fs/namei.c:

	        if (!d_can_lookup(nd->path.dentry)) {
			err = -ENOTDIR;
                        break;
		}

going all the way to path_init -> path_openat -> do_filp_open -> user.


Could then add a break in gdb on the err = -ENOTDIR instruction:
#0  link_path_walk (name=0xffff88042b47b027 "f", nd=0xffff88042c19eff8)
    at fs/namei.c:1845
#1  0xffffffff81209209 in path_init (dfd=<optimized out>, name=<optimized out>, 
    flags=64, nd=0x1 <irq_stack_union+1>) at fs/namei.c:1952
#2  0xffffffff8120bd42 in path_openat (dfd=<optimized out>, pathname=0xffff88042b47b000, 
    nd=0xffff88042a9cfe28, op=0xffff88042a9cff1c, flags=65) at fs/namei.c:3230
#3  0xffffffff8120d8e9 in do_filp_open (dfd=-100, pathname=0xffff88042b47b000, 
    op=0xffff88042a9cff1c) at fs/namei.c:3280
#4  0xffffffff811fb2d7 in do_sys_open (dfd=683933728, filename=<optimized out>, 
    flags=<optimized out>, mode=<optimized out>) at fs/open.c:1010
#5  0xffffffff811fb3fe in SYSC_open (mode=<optimized out>, flags=<optimized out>, 
    filename=<optimized out>) at fs/open.c:1028
#6  SyS_open (filename=<optimized out>, flags=<optimized out>, mode=<optimized out>)
    at fs/open.c:1023

Unfortunately can't seem to get much more out of it, nd->path is borked
by the time gdb gets here:
(gdb) p nd->path
$1 = {mnt = 0x6f666e69000064, dentry = 0x7379656b64616564}

Looking at other values around:
 - next->dentry seems to be the last dir (need to rename directories in
 my test to check, bad idea to name them all the same)
 - name is the name of the file that does exist

It's easy enough to reproduce for me with the script I got, so happy to
give more infos if someone has an idea...

-- 
Dominique