Re: panic in do_last()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 17, 2014 at 07:16:30PM -0700, Lin Ming wrote:
> (gdb) list *do_last+0x7d2
> 0xffffffff811095a5 is in do_last (/home/mlin/linux/fs/namei.c:3036).
> 3031 if ((open_flag & O_CREAT) && d_is_dir(nd->path.dentry))
> 3032            goto out;
> 3033 error = -ENOTDIR;
> 3034 if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
> 3035            goto out;
> 3036 if (!S_ISREG(nd->inode->i_mode))
> 3037            will_truncate = false;

Aha, so my guess in another posting was correct.  OK...

So it's not about RCU case at all - if dentry changes under us
in lazy mode, we'll simply fail when we get to checking d_seq.  It's
non-lazy case + transition from negative to positive that causes the
trouble.

Another piece of breakage in there is should_follow_link() directly
afterwards - there the problem is with false negatives.  I.e. we
see new dentry->d_inode, but not the new dentry->d_flags.

I wonder if the right fix would be simply
	if (!inode || d_is_negative(dentry))
bailing out unless both updates are seen.  Probably cheaper than any
games with barriers...

Comments?
--
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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux