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

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

On Tue, Oct 21, 2014 at 01:34:57PM +0000, Drokin, Oleg wrote:

> I think it makes sense indeed.
> The "get rid of duplicate mountpoint checks" patch has a hunk at ll_link
> that looks like it belongs to "kill ll_link_generic()" patch,
> otherwise the intermediate result is somewhat strange.

Thanks; fixed and force-pushed.

> > Another question: what's wrong with d_splice_alias() or d_materialise_unique()?
> > I.e. why do we need ll_splice_alias()?  I have patches in local queue
> 
> We used to need it to also find and reuse invalid aliases, so that the dentry
> cache does not get out of control with constant dentry invalidations we have.
> 
> I checked the code and now that d_splice_alias is calling __d_find_any_alias
> that seems to just pick the first alias off the list, we should be fine

ITYM "the one and only".  That's pretty much what d_splice_alias() is about -
we do not allow more than one dentry (be it hashed or not) for a directory
inode, so d_add() variant that can run into directory inode already with a
dentry _must_ use that existing dentry instead of what it's been given.
That's why we need it to be able to move a preexisting dentry in place of
the one it's been given and return a new reference to that preexisting
dentry.  For non-directories and for directories that have no aliases it's
just d_add() and return NULL.

> with just using generic d_splice_alias.

BTW, mind if we kill ll_umode_t?  This kind of compat wrappers is the wrong
way - it should be "supply an equivalent of more recent kernel stuff when
builds on older kernels".