diff for duplicates of <20160125180234.GA26732@arm.com> diff --git a/a/content_digest b/N1/content_digest index 33db144..7ffa54d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -36,7 +36,15 @@ linux-mips@linux-mips.org x86@kernel.org user-mode-linux-devel@lists.sourceforge.net - " adi-buildroot-devel@lists.sourceforg\0" + adi-buildroot-devel@lists.sourceforge.net + linux-sh@vger.kernel.org + linux-xtensa@linux-xtensa.org + xen-devel@lists.xenproject.org + Ralf Baechle <ralf@linux-mips.org> + Ingo Molnar <mingo@kernel.org> + ddaney.cavm@gmail.com + james.hogan@imgtec.com + " Michael Ellerman <mpe@ellerman.id.au>\0" "\00:1\0" "b\0" "Hi Paul,\n" @@ -216,4 +224,4 @@ "\n" Will -8ad3a81acd3ba99de2b9ce79909bcdd472574a7f046ed450657a4d53d61efb49 +a0d4a66b0a0710a79290bf3f616946946bde7e3733d1b07ac0b1abd71ada3515
diff --git a/a/1.txt b/N2/1.txt index 2684cf9..940aa75 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -130,21 +130,21 @@ be a bit of a misnomer. > +chain of smp_store_release()/smp_load_acquire() pairs, the following > +outcome is prohibited: > + -> + r0 == 1 && r1 == 1 && r2 == 1 +> + r0 = 1 && r1 = 1 && r2 = 1 > + > +Furthermore, because of the release-acquire relationship between cpu0() > +and cpu1(), cpu1() must see cpu0()'s writes, so that the following > +outcome is prohibited: > + -> + r1 == 1 && r5 == 0 +> + r1 = 1 && r5 = 0 > + > +However, the transitivity of release-acquire is local to the participating > +CPUs and does not apply to cpu3(). Therefore, the following outcome > +is possible: > + -> + r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 +> + r0 = 0 && r1 = 1 && r2 = 1 && r3 = 0 && r4 = 0 -I think you should be completely explicit and include r5 == 1 here, too. +I think you should be completely explicit and include r5 = 1 here, too. Also -- where would you add the smp_mb__after_release_acquire to fix (i.e. forbid) this? Immediately after cpu1()'s read of y? @@ -164,7 +164,7 @@ Also -- where would you add the smp_mb__after_release_acquire to fix > +-not- ensure that any particular value will be read. Therefore, the > +following outcome is possible: > + -> + r0 == 0 && r1 == 0 && r2 == 0 && r5 == 0 +> + r0 = 0 && r1 = 0 && r2 = 0 && r5 = 0 > + > +Note that this outcome can happen even on a mythical sequentially > +consistent system where nothing is ever reordered. diff --git a/a/content_digest b/N2/content_digest index 33db144..44fc6db 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -171,21 +171,21 @@ "> +chain of smp_store_release()/smp_load_acquire() pairs, the following\n" "> +outcome is prohibited:\n" "> +\n" - "> +\tr0 == 1 && r1 == 1 && r2 == 1\n" + "> +\tr0 = 1 && r1 = 1 && r2 = 1\n" "> +\n" "> +Furthermore, because of the release-acquire relationship between cpu0()\n" "> +and cpu1(), cpu1() must see cpu0()'s writes, so that the following\n" "> +outcome is prohibited:\n" "> +\n" - "> +\tr1 == 1 && r5 == 0\n" + "> +\tr1 = 1 && r5 = 0\n" "> +\n" "> +However, the transitivity of release-acquire is local to the participating\n" "> +CPUs and does not apply to cpu3(). Therefore, the following outcome\n" "> +is possible:\n" "> +\n" - "> +\tr0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0\n" + "> +\tr0 = 0 && r1 = 1 && r2 = 1 && r3 = 0 && r4 = 0\n" "\n" - "I think you should be completely explicit and include r5 == 1 here, too.\n" + "I think you should be completely explicit and include r5 = 1 here, too.\n" "\n" "Also -- where would you add the smp_mb__after_release_acquire to fix\n" "(i.e. forbid) this? Immediately after cpu1()'s read of y?\n" @@ -205,7 +205,7 @@ "> +-not- ensure that any particular value will be read. Therefore, the\n" "> +following outcome is possible:\n" "> +\n" - "> +\tr0 == 0 && r1 == 0 && r2 == 0 && r5 == 0\n" + "> +\tr0 = 0 && r1 = 0 && r2 = 0 && r5 = 0\n" "> +\n" "> +Note that this outcome can happen even on a mythical sequentially\n" "> +consistent system where nothing is ever reordered.\n" @@ -216,4 +216,4 @@ "\n" Will -8ad3a81acd3ba99de2b9ce79909bcdd472574a7f046ed450657a4d53d61efb49 +ad0b26429894061b39aa9ec9507bbc9072f829ea0bbecaee0be9c837379f0fc6
diff --git a/a/content_digest b/N3/content_digest index 33db144..7d48d89 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -8,35 +8,10 @@ "ref\020160114212913.GF3818@linux.vnet.ibm.com\0" "ref\020160115085554.GF3421@worktop\0" "ref\020160115173912.GU3818@linux.vnet.ibm.com\0" - "From\0Will Deacon <will.deacon@arm.com>\0" - "Subject\0Re: [v3,11/41] mips: reuse asm-generic/barrier.h\0" + "From\0will.deacon@arm.com (Will Deacon)\0" + "Subject\0[v3,11/41] mips: reuse asm-generic/barrier.h\0" "Date\0Mon, 25 Jan 2016 18:02:34 +0000\0" - "To\0Paul E. McKenney <paulmck@linux.vnet.ibm.com>\0" - "Cc\0Peter Zijlstra <peterz@infradead.org>" - Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - Michael S. Tsirkin <mst@redhat.com> - linux-kernel@vger.kernel.org - Arnd Bergmann <arnd@arndb.de> - linux-arch@vger.kernel.org - Andrew Cooper <andrew.cooper3@citrix.com> - Russell King - ARM Linux <linux@arm.linux.org.uk> - virtualization@lists.linux-foundation.org - Stefano Stabellini <stefano.stabellini@eu.citrix.com> - Thomas Gleixner <tglx@linutronix.de> - Ingo Molnar <mingo@elte.hu> - H. Peter Anvin <hpa@zytor.com> - Joe Perches <joe@perches.com> - David Miller <davem@davemloft.net> - linux-ia64@vger.kernel.org - linuxppc-dev@lists.ozlabs.org - linux-s390@vger.kernel.org - sparclinux@vger.kernel.org - linux-arm-kernel@lists.infradead.org - linux-metag@vger.kernel.org - linux-mips@linux-mips.org - x86@kernel.org - user-mode-linux-devel@lists.sourceforge.net - " adi-buildroot-devel@lists.sourceforg\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Hi Paul,\n" @@ -216,4 +191,4 @@ "\n" Will -8ad3a81acd3ba99de2b9ce79909bcdd472574a7f046ed450657a4d53d61efb49 +2cd29345ec9a89752716fd5ea32fda708798230967167c61105940f4b07d0751
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.