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...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
