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.