Re: panic in do_last()

[Al Viro <viro@ZenIV.linux.org.uk>]

On Fri, Apr 18, 2014 at 02:57:50AM +0100, Al Viro wrote:

> Where is it in do_last()?  Hard to tell without even the hex dump of
> oopsing code (and trying to reproduce it here hasn't produced any oopsen
> so far).

Hmm...  Still no oopsen, but it looks like it *is* possible to get
screwed there.  RCU mode isn't a problem, AFAICS (we'll fail on d_seq
mismatch in complete_walk() and that will be the end of it), but
non-lazy mode *can* get buggered.  We are holding a reference to
nd->path.dentry and that's enough to prevent positive-to-negative
transition, but negative-to-positive is fair game.  So it does
happen and we end up with nd->inode being set to NULL.  And _that_
promptly blows up on
        if (!S_ISREG(nd->inode->i_mode))
                will_truncate = false;
Actually, it might very well be the only source of breakage - that late
in the game (already out of RCU mode, for starters) we don't give a damn
about nd->inode.

Ah, actually there's also
                BUG_ON(inode != path->dentry->d_inode);
in symlink case (similar "negative to positive", but it will be a symlink(2),
not creat(2)).  Pointless BUG_ON, actually...

The reason why your reordering hadn't done any good is that CPU cache is free
to reorder behind your back - no barriers between these two stores.

I'd still like the disassembly of your do_last() and the missing hex dump...