Re: Stupid VFS name lookup interface..

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

On Tue, May 21, 2013 at 03:22:44PM -0700, Linus Torvalds wrote:
> The *one* insane exception is ncpfs, which actually wants to look at
> the parent (ie directory) inode data in order to decide if it should
> use a case sensitive hash or not. However, even in that case, I'd
> argue that we could just optimistically do a
> ACCESS_ONCE(dentry->d_inode) and do the compare using the information
> we got from that.
> 
> Because we don't care if the dentry->d_inode is unstable: if we got
> some stale inode, we would hit the dentry_rcuwalk_barrier() case for
> that parent when we later check the sequence numbers. So then we'd
> throw away the comparison result anyway.  We check both the dentry and
> the parent sequence count in lookup_fast(), verifying that they've
> been stable over the sequence.
> 
> So as far as I can tell, the only thing we should worry about might be
> a NULL pointer due to a concurrent rmdir(), but the identity of the
> inode itself we really don't care too much about. Take one or the
> other, and don't crash on NULL.
> 
> There's a similat case going on in proc_sys_compare(). Same logic applies.

In principle, yes, but...  I wonder if those two cases are actually
safe (especially ncpfs) right now.  We dereference the parent inode
there and that could get ugly, whether we've got it from caller or
as ->d_inode.  Let me dig around in that code a bit, OK?

Al, enjoying the excuse to take a break from ->readdir() code audit ;-/