Re: [PATCH] vfs: fix race in rcu lookup of pruned dentry

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

On Sun, Jul 17, 2011 at 04:38:24PM -0700, Linus Torvalds wrote:
> On Sun, Jul 17, 2011 at 4:16 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > OR
> >
> > ?- keep part of the patch from Hugh, treating negative in RCU mode as
> > "need to unlazy".
> 
> No, urgh, that's horrible.
> 
> Not being able to do an RCU lookup of negative dentries would be
> really sad. There are some loads where a negative dentry is the
> *common* case.

No.  Check the patch, please - what it does is exactly "if RCU lookup
in the middle of pathname gave us a negative dentry, check that it's
really negative ASAP".

Negative on the last component is not affected by that and there we
*do* go unlazy immediately anyway.  If dentry in the middle of pathname
is really negative and not stale, we'll get unlazy_walk() check its
->d_seq and fall through the rest - all the way to failure exit in
walk_component().  Yes, we'll bump and drop ->d_count.  On that
negative dentry in the middle.

On the other hand, if that sucker is stale, unlazy_walk() will check
->d_seq and bugger off.  And no matter what we do, that pathname
resolution is going to have to be done in non-RCU mode at that point
and earlier is better.

Your variant could only lead to walking deeper into the tree before
we discover a stale dentry.  Because it *can't* have non-stale
descendents anymore.  Just more work for us...

IOW, once we run into negative dentry in RCU mode in do_lookup(), we
really need to drop out of RCU mode ASAP.  Note that it's *NOT* about
not finding negative dentries in RCU dcache lookups or any such
silliness - that, of course, would be dumb.