From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752348AbbJNAKJ (ORCPT ); Tue, 13 Oct 2015 20:10:09 -0400 Received: from ozlabs.org ([103.22.144.67]:45797 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751529AbbJNAKD (ORCPT ); Tue, 13 Oct 2015 20:10:03 -0400 Message-ID: <1444781400.12197.4.camel@ellerman.id.au> Subject: Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier From: Michael Ellerman To: Boqun Feng Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Peter Zijlstra , Ingo Molnar , Benjamin Herrenschmidt , Paul Mackerras , Thomas Gleixner , Will Deacon , "Paul E. McKenney" , Waiman Long , Davidlohr Bueso , stable@vger.kernel.org Date: Wed, 14 Oct 2015 11:10:00 +1100 In-Reply-To: <1444660220-25559-1-git-send-email-boqun.feng@gmail.com> References: <1444659246-24769-1-git-send-email-boqun.feng@gmail.com> <1444660220-25559-1-git-send-email-boqun.feng@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2015-10-12 at 22:30 +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"). > > Cc: # 3.4.y- > Signed-off-by: Boqun Feng > --- > arch/powerpc/include/asm/cmpxchg.h | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) Hi Boqun, Thanks for fixing this. In future you should send a patch like this as a separate patch. I've not been paying attention to it because I assumed it was part of your full series and was still under discussion like the other patches. I don't think we've seen any crashes caused by this have we? So I guess I'll put it in next to let it get some wider testing rather than sending it straight to Linus. To be clear you're doing: > - PPC_RELEASE_BARRIER > + PPC_ATOMIC_ENTRY_BARRIER Which is correct but doesn't actually change anything at the moment, because both macros turn into LWSYNC. On the other hand: > - PPC_ACQUIRE_BARRIER > + PPC_ATOMIC_EXIT_BARRIER Is changing an isync (which is then patched to lwsync on some cpus), with a sync. Also I'm not clear what your stable line means: > Cc: # 3.4.y- Do you mean 3.4 and anything after? I usually write that as 3.4+, but I'm not sure if that's the correct syntax either. cheers