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