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

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

On Tue, Oct 21, 2014 at 03:46:02AM +0000, Drokin, Oleg wrote:

> > 	a) what protects ->d_name in ll_intent_file_open()?  It copies
> > ->d_name.name and ->d_name.len into local variables and proceeds to
> > use those; what's to guarantee that dentry won't get hit with d_move()
> > halfway through that?  None of the locks that would give an exclusion
> > against d_move() appear to be held…
> 
> You are right. We hit something very similar not too long ago.
> > 
> > 	b) what stabilizes *dentryp->d_name in do_statahead_enter()?

> Same as above.
> All of that would go away once we get rid of the wrapper and unroll the
> vfs ops.
> 
> Hopefully this makes at least some sense to you.

OK...  I'd gone and ripped some of that stuff out today; see if what's in
vfs.git#for-oleg makes sense...

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
(soon to show up in for-next) that merge d_splice_alias() and
d_materialise_unique(), essentially teaching the former to deal with one
case d_materialise_unique() can handle while d_splice_alias() couldn't.
If you need something not covered by those, it would be interesting to
find out if it would make sense to fold _that_ into d_splice_alias() as well...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html