On Fri, Sep 27, 2013 at 04:50:07PM +0200, Peter Zijlstra wrote: > On Fri, Sep 27, 2013 at 07:34:55AM -0700, Joe Perches wrote: > > That would make it seem as if all barriers are SMP no? > > I would think any memory barrier is ordering against someone else; if > not smp then a device/hardware -- like for instance the hardware page > table walker. > > Barriers are fundamentally about order; and order only makes sense if > there's more than 1 party to the game. Oddly enough, there is one exception that proves the rule... On Itanium, suppose we have the following code, with x initially equal to zero: CPU 1: ACCESS_ONCE(x) = 1; CPU 2: r1 = ACCESS_ONCE(x); r2 = ACCESS_ONCE(x); Itanium architects have told me that it really is possible for CPU 2 to see r1==1 and r2==0. Placing a memory barrier between CPU 2's pair of fetches prevents this, but without any other memory barrier to pair with. > > Maybe just refer to Documentation/memory-barriers.txt > > and/or say something like "please document appropriately" > > Documentation/memory-barriers.txt is always good; appropriately doesn't > seem to quantify anything much at all. Someone might think: > > /* */ > smp_mb(); > > appropriate... I end up doing this: /* */ smp_mb(); /* See above block comment. */ But it would be nice for the prior comment to be recognized as belonging to the memory barrier without the additional "See above" comment. In any case, please feel free to add: Acked-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> to the original checkpatch.pl patch. Thanx, Paul -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>