do we need that smp_wmb() in __d_alloc()?

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

On Thu, Mar 10, 2016 at 07:59:51PM +0000, Al Viro wrote:

> int ll_d_init(struct dentry *de)
> {
> 	struct ll_dentry_data *lld = kzalloc(sizeof(*lld), GFP_NOFS);
> 	if (unlikely(!lld))
> 		return -ENOMEM;
> 	lld->lld_invalid = 1;
> 	smp_wmb();	/* read barrier in whatever will find us */
> 	de->d_fsdata = lld;
>         return 0;
> }
> 
> as its ->d_init() and forget about all that mess.
> 
> Objections, better ideas?

Speaking of barriers - why do we need one there at all?  In __d_alloc(), that
is.  Look: callers of __d_alloc() are:
	* d_alloc() - cycles parent's ->d_lock, inserts into the list of
parent's children.  Anyone observing it on that list of children will be
holding the same parent's ->d_lock.  And anyone finding it in any other way
will have to observe the effect of store done after the write barrier in
spin_unlock.
	* __d_obtain_alias() - same story, only it's ->i_lock of the inode
and ->d_lock of dentry itself.

There's also d_alloc_pseudo() and d_make_root(); I suspect that for
d_make_root() an implicit barrier in unlocking ->s_umount would serve,
but in any case, wouldn't it make more sense to lift that smp_wmb() from
__d_alloc() to d_alloc_pseudo() and d_make_root()?  Linus, do you see
any problems with that?  I don't really trust my taste wrt barriers, so...