Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

On Mon, 20 Jun 2016, Andreas Schwab wrote: > Peter Zijlstra writes: > > > Could either of you comment on the below patch? > > > > All atomic functions that return a value should imply full memory > > barrier semantics -- this very much includes a compiler barrier / > > memory clobber. > > I

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Peter Zijlstra writes: > Could either of you comment on the below patch? > > All atomic functions that return a value should imply full memory > barrier semantics -- this very much includes a compiler barrier / memory > clobber. I wonder if it is possible to find a case where this makes a real d

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Could either of you comment on the below patch? All atomic functions that return a value should imply full memory barrier semantics -- this very much includes a compiler barrier / memory clobber. --- arch/m68k/include/asm/atomic.h | 19 --- arch/m68k/include/asm/cmpxchg.h |

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Hi Peter, On Thu, Jun 16, 2016 at 7:44 PM, Peter Zijlstra wrote: > On Thu, Jun 16, 2016 at 05:04:24PM +0200, Andreas Schwab wrote: >> Peter Zijlstra writes: >> >> > If not, do you want me to 'fix' this or just remove the comment? >> >> It's not broken, so nothing to fix. > > Its non obvious code

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Peter Zijlstra writes: > On Thu, Jun 16, 2016 at 05:04:24PM +0200, Andreas Schwab wrote: >> Peter Zijlstra writes: >> >> > If not, do you want me to 'fix' this or just remove the comment? >> >> It's not broken, so nothing to fix. > > Its non obvious code, that's usually plenty reason to change

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

On Thu, Jun 16, 2016 at 05:04:24PM +0200, Andreas Schwab wrote: > Peter Zijlstra writes: > > > If not, do you want me to 'fix' this or just remove the comment? > > It's not broken, so nothing to fix. Its non obvious code, that's usually plenty reason to change it. Geert, you maintain this stuf

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Peter Zijlstra writes: > If not, do you want me to 'fix' this or just remove the comment? It's not broken, so nothing to fix. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different.

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

On Thu, Jun 16, 2016 at 04:37:36PM +0200, Andreas Schwab wrote: > Peter Zijlstra writes: > > > So the "2" input operand actually sets the value of "=&d" (tmp), how > > creative... > > That was the only way to do it when this was written. Fair enough; do you still support a compiler old enough t

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Peter Zijlstra writes: > So the "2" input operand actually sets the value of "=&d" (tmp), how > creative... That was the only way to do it when this was written. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

On Thu, Jun 16, 2016 at 02:53:09PM +0200, Andreas Schwab wrote: > Peter Zijlstra writes: > > OK, care to elucidate? Clearly I need help reading this. > > grep '2.*atomic_read' Much thanks to your detailed answer I found yet another obscure inline asm syntax 'feature'. So the "2" input operand

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Peter Zijlstra writes: > On Thu, Jun 16, 2016 at 02:43:29PM +0200, Andreas Schwab wrote: >> Peter Zijlstra writes: >> >> > +/* >> >> > + * Am I reading these CAS loops right in that %2 is the old value and >> >> > the first >> >> > + * iteration uses an uninitialized value? >> >> > + * >> >> >

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

On Thu, Jun 16, 2016 at 02:43:29PM +0200, Andreas Schwab wrote: > Peter Zijlstra writes: > >> > +/* > >> > + * Am I reading these CAS loops right in that %2 is the old value and > >> > the first > >> > + * iteration uses an uninitialized value? > >> > + * > >> > + * Would it not make sense to add

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Peter Zijlstra writes: > On Thu, Jun 16, 2016 at 12:08:27PM +0200, Geert Uytterhoeven wrote: > >> > #ifdef CONFIG_RMW_INSNS >> > >> > +/* >> > + * Am I reading these CAS loops right in that %2 is the old value and the >> > first >> > + * iteration uses an uninitialized value? >> > + * >> > + *

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

On Thu, Jun 16, 2016 at 12:08:27PM +0200, Geert Uytterhoeven wrote: > > #ifdef CONFIG_RMW_INSNS > > > > +/* > > + * Am I reading these CAS loops right in that %2 is the old value and the > > first > > + * iteration uses an uninitialized value? > > + * > > + * Would it not make sense to add: tmp

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Hi Peter, On Tue, May 31, 2016 at 12:19 PM, Peter Zijlstra wrote: > Implement FETCH-OP atomic primitives, these are very similar to the > existing OP-RETURN primitives we already have, except they return the > value of the atomic variable _before_ modification. > > This is especially useful for i

[PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

Implement FETCH-OP atomic primitives, these are very similar to the existing OP-RETURN primitives we already have, except they return the value of the atomic variable _before_ modification. This is especially useful for irreversible operations -- such as bitops (because it becomes impossible to re