Re: [RFC] lustre treatment of dentry->d_name

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

On Wed, Oct 22, 2014 at 01:48:48AM +0000, Drokin, Oleg wrote:

> Ah! I see now.
> We do the "pick alias from a list" for everything, not just for the directories.
> So that difference is still missing and as such there is a fear if we
> convert to d_splice_alias in its current form, dcache would explode
> from all the gazillions of invalid and unhashed dentries we produce during
> operations.

Interesting...  Where do those gazillions come from?  AFAICS, your
->d_revalidate() does that only when you get LOOKUP_OPEN | LOOKUP_CREATE
in flags, i.e. on the final component of pathname at open() with O_CREAT.
Hmm...  So basically you are trying to force them into ->atomic_open()
codepath?  Fine, but... why not simply have ->open() pick what hadn't
gone through ->atomic_open()?

Check what nfs4_file_open() is doing; if you find out that the damn thing
*was* stale (i.e. that you really need a different inode, etc.), it's not
a problem - d_drop() and return -EOPENSTALE; VFS will repeat lookups.
Note that do_dentry_open() doesn't strip O_CREAT from file->f_flags until
after return from ->open().  So you can see O_CREAT in ->open() just
fine - this case is easy to distinguish there.

Incidentally, why the hell do you have separate ll_revalidate_nd() and
ll_revalidate_dentry()?  I realize that it'll be inlined by compiler (the
only call of the latter is tail-call with identical arguments from the
former), but...

Another nasty question: is d_need_statahead() safe in RCU pathwalk mode?
When are ll_dentry_data and ll_inode_info freed?  Ditto for ->lli_sai.
Sure, actual freeing of struct inode and struct dentry is RCU-delayed,
but from the quick glance it seems that freeing those guys isn't...