From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752033AbdHCOFI (ORCPT ); Thu, 3 Aug 2017 10:05:08 -0400 Received: from mail-pg0-f51.google.com ([74.125.83.51]:33257 "EHLO mail-pg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751220AbdHCOFH (ORCPT ); Thu, 3 Aug 2017 10:05:07 -0400 Date: Thu, 3 Aug 2017 22:05:16 +0800 From: Boqun Feng To: Will Deacon Cc: "Paul E. McKenney" , Peter Zijlstra , linux-kernel@vger.kernel.org, Ingo Molnar , Thomas Gleixner , Randy Dunlap Subject: Re: [RFC][PATCH v3]: documentation,atomic: Add new documents Message-ID: <20170803135718.wx2lwlm5aglvhyh5@tardis> References: <20170726124750.vktrn5zi2gmpzfru@tardis> <20170731090535.rjgnoewqg7mhzr55@hirez.programming.kicks-ass.net> <20170731110403.ou3zqsp3uviqorkz@tardis> <20170731174345.GL3730@linux.vnet.ibm.com> <20170801090121.edo7mekhw3sann4h@hirez.programming.kicks-ass.net> <20170801101900.GB8702@arm.com> <20170801114744.evjjfviqhu5kgu7v@hirez.programming.kicks-ass.net> <20170801121713.GH8702@arm.com> <20170801161412.GW3730@linux.vnet.ibm.com> <20170802094531.GA15748@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i6ckhvkqnck4zdvl" Content-Disposition: inline In-Reply-To: <20170802094531.GA15748@arm.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --i6ckhvkqnck4zdvl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Will, On Wed, Aug 02, 2017 at 10:45:32AM +0100, Will Deacon wrote: [...] >=20 > It's worth noting that we don't have the problem with any value-returning > atomics, so all flavours of xchg in this test would be forbidden on arm64 > too. >=20 > > C C-WillDeacon-MP+o-r+ai-rmb-o.litmus > >=20 > > (* > > * Expected result: Never. > > * > > * Desired litmus test, with atomic_inc() emulated by xchg_relaxed(): > > * > > * WRITE_ONCE(x, 1); atomic_inc(&y); > > * r0 =3D xchg_release(&y, 5); smp_rmb(); > > * r1 =3D READ_ONCE(x); > > * > > * > > * WARN_ON(r0 =3D=3D 0 && r1 =3D=3D 0); > > *) > >=20 > > { > > } > >=20 > > P0(int *x, int *y) > > { > > WRITE_ONCE(*x, 1); > > r0 =3D xchg_release(y, 5); > > } > >=20 > > P1(int *x, int *y) > > { > > r2 =3D xchg_relaxed(y, 1); > > smp_rmb(); > > r1 =3D READ_ONCE(*x); > > } > >=20 > > exists > > (0:r0=3D0 /\ 1:r1=3D0) > >=20 How about a litmus test like this? C C-AMO-global-transitivity.litmus =20 { } =20 P0(int *x, int *y) { WRITE_ONCE(*x, 1); r0 =3D xchg_release(y, 5); } =20 P1(int *y, int *z) { atomic_inc(y); smp_mb(); r1 =3D READ_ONCE(*z); } P2(int *x, int *z) { WRITE_ONCE(*z, 1); smp_mb(); r2 =3D READ_ONCE(*x); } =20 exists (0:r0=3D0 /\ 1:r1=3D0 /\ 2:r2=3D0 ) Should we forbid the outcome in the exists-clause? I ask because I want to know whether we can just treat atomic_inc() as a store, because if I replace atomic_inc() with a WRITE(*y, 6), IIUC, the current model says this could happen. Thoughts? Regards, Boqun --i6ckhvkqnck4zdvl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAlmDLZcACgkQSXnow7UH +rh3Bgf9E8dl1MdqVU5ym1QyZ8A1toBfiWAgPqInWDd5BB9usUBrDUfbgDbxr0Hk NlkR7cKweTNL4+ZvZ8FwQNZMuRaa6CYQAnxFMLqYgGbuEWYd7zDuEjfiZnep9/vo CE5TCUlgblGiXTatYOX5NTOUVUANHkenWCui+ThfbZmz3FYYip5CGPN6oB2nLOYb ebk95R2IqK4Ack4KgNSG49K2nhPfMG35Aqolk0ssOZTQ6IM2KNbn9esW9/ozv/Et FJCSUKZqHYVfCE+6tuJlSC1d4uvJDIIfUuqjQAkUaY4s5z1pFn3QqunubHcmq+pK x/9xkNwc/nU9dy1GS0a9zoyy2tc7Qw== =Vc04 -----END PGP SIGNATURE----- --i6ckhvkqnck4zdvl--