From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will.deacon@arm.com>,
Waiman Long <waiman.long@hp.com>,
Davidlohr Bueso <dave@stgolabs.net>,
stable@vger.kernel.org
Subject: Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
Date: Wed, 14 Oct 2015 13:19:17 -0700 [thread overview]
Message-ID: <20151014201916.GB3910@linux.vnet.ibm.com> (raw)
In-Reply-To: <1444838161-17209-2-git-send-email-boqun.feng@gmail.com>
On Wed, Oct 14, 2015 at 11:55:56PM +0800, Boqun Feng wrote:
> According to memory-barriers.txt, xchg, cmpxchg and their atomic{,64}_
> versions all need to imply a full barrier, however they are now just
> RELEASE+ACQUIRE, which is not a full barrier.
>
> So replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
> PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
> __{cmp,}xchg_{u32,u64} respectively to guarantee a full barrier
> semantics of atomic{,64}_{cmp,}xchg() and {cmp,}xchg().
>
> This patch is a complement of commit b97021f85517 ("powerpc: Fix
> atomic_xxx_return barrier semantics").
>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> Cc: <stable@vger.kernel.org> # 3.4+
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> ---
> arch/powerpc/include/asm/cmpxchg.h | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cmpxchg.h b/arch/powerpc/include/asm/cmpxchg.h
> index ad6263c..d1a8d93 100644
> --- a/arch/powerpc/include/asm/cmpxchg.h
> +++ b/arch/powerpc/include/asm/cmpxchg.h
> @@ -18,12 +18,12 @@ __xchg_u32(volatile void *p, unsigned long val)
> unsigned long prev;
>
> __asm__ __volatile__(
> - PPC_RELEASE_BARRIER
> + PPC_ATOMIC_ENTRY_BARRIER
This looks to be the lwsync instruction.
> "1: lwarx %0,0,%2 \n"
> PPC405_ERR77(0,%2)
> " stwcx. %3,0,%2 \n\
> bne- 1b"
> - PPC_ACQUIRE_BARRIER
> + PPC_ATOMIC_EXIT_BARRIER
And this looks to be the sync instruction.
> : "=&r" (prev), "+m" (*(volatile unsigned int *)p)
> : "r" (p), "r" (val)
> : "cc", "memory");
Hmmm...
Suppose we have something like the following, where "a" and "x" are both
initially zero:
CPU 0 CPU 1
----- -----
WRITE_ONCE(x, 1); WRITE_ONCE(a, 2);
r3 = xchg(&a, 1); smp_mb();
r3 = READ_ONCE(x);
If xchg() is fully ordered, we should never observe both CPUs'
r3 values being zero, correct?
And wouldn't this be represented by the following litmus test?
PPC SB+lwsync-RMW2-lwsync+st-sync-leading
""
{
0:r1=1; 0:r2=x; 0:r3=3; 0:r10=0 ; 0:r11=0; 0:r12=a;
1:r1=2; 1:r2=x; 1:r3=3; 1:r10=0 ; 1:r11=0; 1:r12=a;
}
P0 | P1 ;
stw r1,0(r2) | stw r1,0(r12) ;
lwsync | sync ;
lwarx r11,r10,r12 | lwz r3,0(r2) ;
stwcx. r1,r10,r12 | ;
bne Fail0 | ;
mr r3,r11 | ;
Fail0: | ;
exists
(0:r3=0 /\ a=2 /\ 1:r3=0)
I left off P0's trailing sync because there is nothing for it to order
against in this particular litmus test. I tried adding it and verified
that it has no effect.
Am I missing something here? If not, it seems to me that you need
the leading lwsync to instead be a sync.
Of course, if I am not missing something, then this applies also to the
value-returning RMW atomic operations that you pulled this pattern from.
If so, it would seem that I didn't think through all the possibilities
back when PPC_ATOMIC_EXIT_BARRIER moved to sync... In fact, I believe
that I worried about the RMW atomic operation acting as a barrier,
but not as the load/store itself. :-/
Thanx, Paul
> @@ -61,12 +61,12 @@ __xchg_u64(volatile void *p, unsigned long val)
> unsigned long prev;
>
> __asm__ __volatile__(
> - PPC_RELEASE_BARRIER
> + PPC_ATOMIC_ENTRY_BARRIER
> "1: ldarx %0,0,%2 \n"
> PPC405_ERR77(0,%2)
> " stdcx. %3,0,%2 \n\
> bne- 1b"
> - PPC_ACQUIRE_BARRIER
> + PPC_ATOMIC_EXIT_BARRIER
> : "=&r" (prev), "+m" (*(volatile unsigned long *)p)
> : "r" (p), "r" (val)
> : "cc", "memory");
> @@ -151,14 +151,14 @@ __cmpxchg_u32(volatile unsigned int *p, unsigned long old, unsigned long new)
> unsigned int prev;
>
> __asm__ __volatile__ (
> - PPC_RELEASE_BARRIER
> + PPC_ATOMIC_ENTRY_BARRIER
> "1: lwarx %0,0,%2 # __cmpxchg_u32\n\
> cmpw 0,%0,%3\n\
> bne- 2f\n"
> PPC405_ERR77(0,%2)
> " stwcx. %4,0,%2\n\
> bne- 1b"
> - PPC_ACQUIRE_BARRIER
> + PPC_ATOMIC_EXIT_BARRIER
> "\n\
> 2:"
> : "=&r" (prev), "+m" (*p)
> @@ -197,13 +197,13 @@ __cmpxchg_u64(volatile unsigned long *p, unsigned long old, unsigned long new)
> unsigned long prev;
>
> __asm__ __volatile__ (
> - PPC_RELEASE_BARRIER
> + PPC_ATOMIC_ENTRY_BARRIER
> "1: ldarx %0,0,%2 # __cmpxchg_u64\n\
> cmpd 0,%0,%3\n\
> bne- 2f\n\
> stdcx. %4,0,%2\n\
> bne- 1b"
> - PPC_ACQUIRE_BARRIER
> + PPC_ATOMIC_EXIT_BARRIER
> "\n\
> 2:"
> : "=&r" (prev), "+m" (*p)
> --
> 2.5.3
>
next prev parent reply other threads:[~2015-10-14 20:19 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 15:55 [PATCH tip/locking/core v4 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier Boqun Feng
2015-10-14 20:19 ` Paul E. McKenney [this message]
2015-10-14 21:04 ` Peter Zijlstra
2015-10-14 21:44 ` Paul E. McKenney
2015-10-15 0:53 ` Boqun Feng
2015-10-15 1:22 ` Boqun Feng
2015-10-15 3:07 ` Paul E. McKenney
2015-10-15 3:07 ` Paul E. McKenney
2015-10-15 4:48 ` Boqun Feng
2015-10-15 16:30 ` Paul E. McKenney
2015-10-19 0:19 ` Boqun Feng
2015-10-15 3:11 ` Boqun Feng
2015-10-15 3:33 ` Paul E. McKenney
2015-10-15 10:35 ` Will Deacon
2015-10-15 14:40 ` Boqun Feng
2015-10-15 14:50 ` Will Deacon
2015-10-15 16:29 ` Paul E. McKenney
2015-10-15 15:42 ` Paul E. McKenney
2015-10-15 14:49 ` Boqun Feng
2015-10-15 16:16 ` Paul E. McKenney
2015-10-20 7:15 ` Boqun Feng
2015-10-20 9:21 ` Peter Zijlstra
2015-10-20 21:28 ` Paul E. McKenney
2015-10-21 8:18 ` Peter Zijlstra
2015-10-21 19:36 ` Paul E. McKenney
2015-10-26 2:06 ` Boqun Feng
2015-10-26 2:20 ` Michael Ellerman
2015-10-26 8:55 ` Boqun Feng
2015-10-26 3:20 ` Paul Mackerras
2015-10-26 8:58 ` Boqun Feng
2015-10-21 8:45 ` Boqun Feng
2015-10-21 19:35 ` Paul E. McKenney
2015-10-21 19:48 ` Peter Zijlstra
2015-10-22 12:07 ` Boqun Feng
2015-10-24 10:26 ` Peter Zijlstra
2015-10-24 11:53 ` Boqun Feng
2015-10-25 13:14 ` Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 2/6] atomics: Add test for atomic operations with _relaxed variants Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 3/6] atomics: Allow architectures to define their own __atomic_op_* helpers Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 4/6] powerpc: atomic: Implement atomic{, 64}_*_return_* variants Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 4/6] powerpc: atomic: Implement atomic{,64}_*_return_* variants Boqun Feng
2015-10-14 15:56 ` [PATCH tip/locking/core v4 5/6] powerpc: atomic: Implement xchg_* and atomic{, 64}_xchg_* variants Boqun Feng
2015-10-14 15:56 ` [PATCH tip/locking/core v4 5/6] powerpc: atomic: Implement xchg_* and atomic{,64}_xchg_* variants Boqun Feng
2015-10-14 15:56 ` [PATCH tip/locking/core v4 6/6] powerpc: atomic: Implement cmpxchg{, 64}_* and atomic{, 64}_cmpxchg_* variants Boqun Feng
2015-10-14 15:56 ` [PATCH tip/locking/core v4 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants Boqun Feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151014201916.GB3910@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=boqun.feng@gmail.com \
--cc=dave@stgolabs.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=waiman.long@hp.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.