Thread (46 messages) 46 messages, 5 authors, 2011-07-20

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

From: Al Viro <viro@ZenIV.linux.org.uk>
Date: 2011-07-17 23:53:17
Also in: lkml

On Sun, Jul 17, 2011 at 04:38:24PM -0700, Linus Torvalds wrote:
On Sun, Jul 17, 2011 at 4:16 PM, Al Viro [off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help