Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants

From	Peter Zijlstra <peterz@infradead.org>
Newsgroups	linux.kernel
Subject	Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants
Date	2015-09-14 13:40 +0200
Message-ID	<q8Ah4-4WS-23@gated-at.bofh.it> (permalink)
References	(5 earlier) <q2tV0-7of-7@gated-at.bofh.it> <q3Z6p-72W-5@gated-at.bofh.it> <q41Bg-21v-21@gated-at.bofh.it> <q4cZI-1tV-27@gated-at.bofh.it> <q7vW9-1Oz-9@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

Sorry for being tardy, I had a wee spell of feeling horrible and then I
procrastinated longer than I should have.

On Fri, Sep 11, 2015 at 01:45:07PM +0100, Will Deacon wrote:

> Peter, any thoughts? I'm not au fait with the x86 memory model, but what
> Paul's saying is worrying.

Right, so Paul is right -- and I completely forgot (I used to know about
that).

So all the TSO archs (SPARC-TSO, x86 (!OOSTORE) and s390) can do
smp_load_acquire()/smp_store_release() with just barrier(), and while:

	smp_store_release(&x);
	smp_load_acquire(&x);

will provide full order by means of the address dependency,

	smp_store_release(&x);
	smp_load_acquire(&y);

will not. Because the one reorder TSO allows is exactly that one.

> Peter -- if the above reordering can happen on x86, then moving away
> from RCpc is going to be less popular than I hoped...

Sadly yes.. We could of course try and split LOCK from ACQUIRE again,
but I'm not sure that's going to help anything except confusion.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

Re: [RFC 3/5] powerpc: atomic: implement  atomic{,64}_{add,sub}_return_* variants Will Deacon <will.deacon@arm.com> - 2015-09-11 14:50 +0200
  Re: [RFC 3/5] powerpc: atomic: implement  atomic{,64}_{add,sub}_return_* variants "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-09-11 19:20 +0200
  Re: [RFC 3/5] powerpc: atomic: implement  atomic{,64}_{add,sub}_return_* variants Peter Zijlstra <peterz@infradead.org> - 2015-09-14 13:40 +0200
    Re: [RFC 3/5] powerpc: atomic: implement  atomic{,64}_{add,sub}_return_* variants Peter Zijlstra <peterz@infradead.org> - 2015-09-14 14:10 +0200
      Re: [RFC 3/5] powerpc: atomic: implement  atomic{,64}_{add,sub}_return_* variants Peter Zijlstra <peterz@infradead.org> - 2015-09-14 14:20 +0200
        Re: [RFC 3/5] powerpc: atomic: implement  atomic{,64}_{add,sub}_return_* variants Will Deacon <will.deacon@arm.com> - 2015-09-14 17:40 +0200
          Re: [RFC 3/5] powerpc: atomic: implement  atomic{,64}_{add,sub}_return_* variants "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-09-14 18:50 +0200

csiph-web