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...
--
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
