Hi Andrea, On Tue, Feb 20, 2018 at 07:45:56PM +0100, Andrea Parri wrote: > Continuing along with the fight against smp_read_barrier_depends() [1] > (or rather, against its improper use), add an unconditional barrier to > cmpxchg. This guarantees that dependency ordering is preserved when a > dependency is headed by an unsuccessful cmpxchg. As it turns out, the > change could enable further simplification of LKMM as proposed in [2]. > > [1] https://marc.info/?l=linux-kernel&m=150884953419377&w=2 > https://marc.info/?l=linux-kernel&m=150884946319353&w=2 > https://marc.info/?l=linux-kernel&m=151215810824468&w=2 > https://marc.info/?l=linux-kernel&m=151215816324484&w=2 > > [2] https://marc.info/?l=linux-kernel&m=151881978314872&w=2 > > Signed-off-by: Andrea Parri <[email protected]> > Acked-by: Peter Zijlstra <[email protected]> > Cc: Will Deacon <[email protected]> > Cc: "Paul E. McKenney" <[email protected]> > Cc: Alan Stern <[email protected]> > Cc: Richard Henderson <[email protected]> > Cc: Ivan Kokshaysky <[email protected]> > Cc: Matt Turner <[email protected]> > Cc: [email protected] > Cc: [email protected] > --- > arch/alpha/include/asm/xchg.h | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/arch/alpha/include/asm/xchg.h b/arch/alpha/include/asm/xchg.h > index 68dfb3cb71454..e2660866ce972 100644 > --- a/arch/alpha/include/asm/xchg.h > +++ b/arch/alpha/include/asm/xchg.h > @@ -128,10 +128,9 @@ ____xchg(, volatile void *ptr, unsigned long x, int size) > * store NEW in MEM. Return the initial value in MEM. Success is > * indicated by comparing RETURN with OLD. > * > - * The memory barrier should be placed in SMP only when we actually > - * make the change. If we don't change anything (so if the returned > - * prev is equal to old) then we aren't acquiring anything new and > - * we don't need any memory barrier as far I can tell. > + * The memory barrier is placed in SMP unconditionally, in order to > + * guarantee that dependency ordering is preserved when a dependency > + * is headed by an unsuccessful operation. > */ > > static inline unsigned long > @@ -150,8 +149,8 @@ ____cmpxchg(_u8, volatile char *m, unsigned char old, > unsigned char new) > " or %1,%2,%2\n" > " stq_c %2,0(%4)\n" > " beq %2,3f\n" > - __ASM__MB > "2:\n" > + __ASM__MB > ".subsection 2\n" > "3: br 1b\n" > ".previous"
It might be better just to add smp_read_barrier_depends() into the cmpxchg macro, then remove all of the __ASM__MB stuff. That said, I don't actually understand how the Alpha cmpxchg or xchg implementations satisfy the memory model, since they only appear to have a barrier after the operation. So MP using xchg: WRITE_ONCE(x, 1) xchg(y, 1) smp_load_acquire(y) == 1 READ_ONCE(x) == 0 would be allowed. What am I missing? Since I'm in the mood for dumb questions, do we need to care about this_cpu_cmpxchg? I'm sure I've seen code that allows concurrent access to per-cpu variables, but the asm-generic implementation of this_cpu_cmpxchg doesn't use READ_ONCE. Will
