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 S1755314AbcBBNS5 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 2 Feb 2016 08:18:57 -0500
Received: from mail-ob0-f179.google.com ([209.85.214.179]:34619 "EHLO
	mail-ob0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754936AbcBBNSy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 2 Feb 2016 08:18:54 -0500
Date: Tue, 2 Feb 2016 21:18:18 +0800
From: Boqun Feng <boqun.feng@gmail.com>
To: Will Deacon <will.deacon@arm.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        "Maciej W. Rozycki" <macro@imgtec.com>,
        David Daney <ddaney@caviumnetworks.com>,
        =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans@mansr.com>,
        Ralf Baechle <ralf@linux-mips.org>, linux-kernel@vger.kernel.org,
        torvalds@linux-foundation.org
Subject: Re: [RFC][PATCH] mips: Fix arch_spin_unlock()
Message-ID: <20160202131818.GF1239@fixme-laptop.cn.ibm.com>
References: <20160128095718.GC30928@arm.com>
 <20160128223131.GV4503@linux.vnet.ibm.com>
 <20160129095958.GA4541@arm.com>
 <20160129102253.GG4503@linux.vnet.ibm.com>
 <20160201135621.GD6828@arm.com>
 <20160202035458.GF6719@linux.vnet.ibm.com>
 <20160202051904.GC1239@fixme-laptop.cn.ibm.com>
 <20160202114559.GA10166@arm.com>
 <20160202121230.GE1239@fixme-laptop.cn.ibm.com>
 <20160202122025.GB10166@arm.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="qoTlaiD+Y2fIM3Ll"
Content-Disposition: inline
In-Reply-To: <20160202122025.GB10166@arm.com>
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


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

On Tue, Feb 02, 2016 at 12:20:25PM +0000, Will Deacon wrote:
[...]
> > > >=20
> > > > Besides, Will, what's the reason of having a locally transitive cha=
in
> > > > termination? Because on some architectures RELEASE->DEPENDENCY pair=
s may
> > > > not be locally transitive?
> > >=20
> > > Well, the following ISA2 test is permitted on ARM:
> > >=20
> > >=20
> > > P0:
> > > Wx=3D1
> > > WyRel=3D1	// rcu_assign_pointer
> > >=20
> > > P1:
> > > Ry=3D1	// rcu_dereference
> >=20
> > What if a <addr> dependency is added here? Same result?
>=20
> Right, that fixes it. So if we're only considering things like:
>=20
>   rcu_dereference
>   <addr>
>   RELEASE
>=20
> then local transitivity should be preserved.
>=20
> I think the same applies to <ctrl>, which seems to match your later
> example.
>=20

Thank you ;-)

Now I understand why you want thoses pairings to be locally transitive
chain terminations, they have more subtle requirements to extend locally
transitive chains and slight different behaviors on different
architectures. It's better for us to put them aside until we figure out
thoses subtle requirements and different behaviors.

Regards,
Boqun

> Will

--qoTlaiD+Y2fIM3Ll
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEcBAABCAAGBQJWsKyUAAoJEEl56MO1B/q4j3AIAKdFNbg+dq6R7OwZNM7LAo9/
oxFECxkqpq5D5TzJfO3rYpCyjrVBunRAwcKzhzpYf4GCz+bLy/qsiv7SEk0LnQX3
JjJlG6IK4yQHGkWkZNdOUFl/Yv5Mnn02TL43ABqLBJoFLeKGm3Klbb5xIMEe2D/9
pBZIASk3Gn4cgK10RXzzSvbqI5XSZ3uCHyd4LaMrYU11UM5Ug8PftDUSv7Db0mCr
3oLy/5+TTKecAlGWHwUl5J4VLa/ClkrXtRVBhjl9LzkST7EZxgMSHMdbvpUzvhxl
citK9BVXldI4R4D0PA5HI+aG2WG8/NEqZYsPWOwDTsGsSVDXOxshB7Hm8sEv7Dc=
=zXDg
-----END PGP SIGNATURE-----

--qoTlaiD+Y2fIM3Ll--