From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751055AbbJJB6c (ORCPT <rfc822;w@1wt.eu>);
	Fri, 9 Oct 2015 21:58:32 -0400
Received: from mail-pa0-f41.google.com ([209.85.220.41]:36703 "EHLO
	mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750753AbbJJB6a (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 9 Oct 2015 21:58:30 -0400
Date: Sat, 10 Oct 2015 09:58:06 +0800
From: Boqun Feng <boqun.feng@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.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>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Waiman Long <waiman.long@hp.com>
Subject: Re: [RFC v2 5/7] powerpc: atomic: Implement cmpxchg{,64}_* and
 atomic{,64}_cmpxchg_* variants
Message-ID: <20151010015805.GA946@fixme-laptop.cn.ibm.com>
References: <1442418575-12297-1-git-send-email-boqun.feng@gmail.com>
 <1442418575-12297-6-git-send-email-boqun.feng@gmail.com>
 <20151001122715.GQ2881@worktop.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP"
Content-Disposition: inline
In-Reply-To: <20151001122715.GQ2881@worktop.programming.kicks-ass.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Peter,

Sorry for replying late.

On Thu, Oct 01, 2015 at 02:27:16PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 16, 2015 at 11:49:33PM +0800, Boqun Feng wrote:
> > Unlike other atomic operation variants, cmpxchg{,64}_acquire and
> > atomic{,64}_cmpxchg_acquire don't have acquire semantics if the cmp part
> > fails, so we need to implement these using assembly.
>=20
> I think that is actually expected and documented. That is, a cmpxchg
> only implies barriers on success. See:
>=20
>   ed2de9f74ecb ("locking/Documentation: Clarify failed cmpxchg() memory o=
rdering semantics")

I probably didn't make myself clear here, my point is that if we use
__atomic_op_acquire() to built *_cmpchg_acquire(For ARM and PowerPC),
the barrier will be implied _unconditionally_, meaning no matter cmp
fails or not, there will be a barrier after the cmpxchg operation.
Therefore we have to use assembly to implement the operations right now.

Regards,
Boqun

--jRHKVT23PllUwdXP
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAABCAAGBQJWGHCmAAoJEEl56MO1B/q4GkMH+wWVfgleFLzIDrURMWc9eHK0
NfCFabgZeeqgiVJqeqGHSkPqMVzfm5RVSshGrsrT7fynUOfzT2vVmDbSsei/nkSm
ADkJr8e6MKiN2PDOfCQoGHWyocOZXHyGo6rKBR5YmAJmf1r/OeYI5ewK9PcWcohV
TtAxdChzrob+moKronElXc7kS0jMAqh7M98o6FxDP3HzQeQFZ4bnauD/yoHlu2sB
9yp8Ael105/LclTIM/9Z9hwHEPI949ASbkYa+BGDvDlJLN49e8wEhouCk5howqzD
WwBP+OwFXbUkOt1mDrCUvsoVeNnRzbTA9Wm01lNXs1F405sDktNF5UczYEo3IyU=
=d3yF
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--