On Thu, Mar 23, 2017 at 3:17 PM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > On Sun, Mar 5, 2017 at 8:18 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >> On Sun, Mar 05, 2017 at 06:33:18PM +0100, Dmitry Vyukov wrote: >> >>> Added more debug output. >>> >>> name_to_handle_at(r4, &(0x7f0000003000-0x6)="2e2f62757300", >>> &(0x7f0000003000-0xd)={0xc, 0x0, "cd21"}, &(0x7f0000002000)=0x0, >>> 0x1000) >>> >>> actually passes name="" because of the overlapping addresses. Flags >>> contain AT_EMPTY_PATH. >> >> Bloody hell... So you end up with name == (char *)&handle->handle_type + 3? >> Looks like it would be a lot more useful to dump the actual contents of >> those suckers right before the syscall... >> >> Anyway, that explains WTF is going on. The bug is in path_init() and >> it triggers when you pass something with dentry allocated by d_alloc_pseudo() >> as dfd, combined with empty pathname. You need to have the file closed >> by another thread, and have that another thread get out of closing syscall >> (close(), dup2(), etc.) before the caller of path_init() gets to >> complete_walk(). We need to make sure that this sucker gets DCACHE_RCUPDATE >> while it's still guaranteed to be pinned down. Could you try to reproduce >> with the patch below applied? >> >> diff --git a/fs/namei.c b/fs/namei.c >> index 6f7d96368734..70840281a41c 100644 >> --- a/fs/namei.c >> +++ b/fs/namei.c >> @@ -2226,11 +2226,16 @@ static const char *path_init(struct nameidata *nd, unsigned flags) >> nd->path = f.file->f_path; >> if (flags & LOOKUP_RCU) { >> rcu_read_lock(); >> - nd->inode = nd->path.dentry->d_inode; >> - nd->seq = read_seqcount_begin(&nd->path.dentry->d_seq); >> + if (unlikely(!(dentry->d_flags & DCACHE_RCUACCESS))) { >> + spin_lock(&dentry->d_lock); >> + dentry->d_flags |= DCACHE_RCUACCESS; >> + spin_unlock(&dentry->d_lock); >> + } >> + nd->inode = dentry->d_inode; >> + nd->seq = read_seqcount_begin(&dentry->d_seq); >> } else { >> path_get(&nd->path); >> - nd->inode = nd->path.dentry->d_inode; >> + nd->inode = dentry->d_inode; >> } >> fdput(f); >> return s; > > > Al, please send this patch officially. I am running with it since then > and have not seen the crashes, nor any other issues that look related. > > Thanks! Al, ping. Please send this patch.