On Tue, Jul 14, 2015 at 12:04:06AM +0100, Paul E. McKenney wrote: > On Tue, Jul 14, 2015 at 12:23:46AM +0200, Peter Zijlstra wrote: > > If we look at the inside of the critical section again -- similar > > argument as before: > > > > *A = a > > smp_mb() > > store M > > load N > > smp_mb() > > *B = b > > > > A and B are fully ordered, and in this case even transitivity is > > provided. > > > > I'm stating that the order of M and N don't matter, only the > > load/stores that are inside the acquire/release are constrained. > > No argument here. > > > IOW, I think smp_mb__after_unlock_lock() already works as advertised > > with all our acquire/release thingies -- as is stated by the > > documentation. > > > > That said, I'm not aware of anybody but RCU actually using this, so its > > not used in that capacity. > > OK, I might actually understand what you are getting at. And, yes, if > someone actually comes up with a need to combine smp_mb__after_unlock_lock() > with something other than locking, we should worry about it at that point. > And probably rename smp_mb__after_unlock_lock() at that point, as well. > Until then, why lock ourselves into semantics that no one needs, and > that it is quite possible that no one will ever need? Given that RCU is currently the only user of this barrier, how would you feel about making the barrier local to RCU and not part of the general memory-barrier API? My main reason for proposing its removal is because I don't want to see it being used (incorrectly) all over the place to order the new RELEASE and ACQUIRE operations I posted separately, at which point we have to try fixing up all the callers or retrofitting some semantics. It doesn't help that memory-barriers.txt lumps things like LOCK and ACQUIRE together, whereas this barrier is currently only intended to be used in conjunction with the former. Will -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
