On Sun, Sep 28, 2014 at 07:05:56PM +0100, Al Viro wrote: > One thing that worries me is the barriers that might be needed on assignments > to ->d_name.name. We should be no worse than we are right now - either RCU > accessors are careful enough with ACCESS_ONCE() and everything's fine, > or they are not, in which case we already have a bug in mainline - swapping > ->d_name followed by dput() and freeing of target is no better than > copying ->d_name from target to source followed by kfree_rcu() of what > used to be ->d_name.name of source. IOW, if RCU lookup could pick > a value of ->d_name.name that got obsolete by d_move() happening > before our read_lock_rcu(), we would be in trouble anyway - it might > already have had its freeing RCU-scheduled and thus not delayed > by read_lock_rcu() done afterwards. So I think the patch below doesn't > introduce new problems of that sort, but I'd really appreciate if RCU > people would take a look at the situation with barriers in that area. > Are those ACCESS_ONCE() in dentry_cmp() and prepend_name() enough, or > do we need some barriers in switch_names() as well? Hmm... OK, dentry_cmp() is doing something similar to open-coded rcu_dereference(). prepend_name() does not, and I really wonder if that's correct... I'm afraid that the answer is "should've been more careful when switching d_path() to RCU", but maybe there's something subtle I'm missing there... I really hate memory ordering rules on alpha ;-/ -- 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
