From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [PATCH 1/2] tools/memory-model: Fix comment in MP+poonceonces.litmus Date: Tue, 19 Feb 2019 18:00:02 -0800 Message-ID: <20190220020002.GC11787@linux.ibm.com> References: <1550616923-4795-1-git-send-email-andrea.parri@amarulasolutions.com> <1550616923-4795-2-git-send-email-andrea.parri@amarulasolutions.com> Reply-To: paulmck@linux.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1550616923-4795-2-git-send-email-andrea.parri@amarulasolutions.com> Sender: linux-kernel-owner@vger.kernel.org To: Andrea Parri Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Alan Stern , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig List-Id: linux-arch.vger.kernel.org On Tue, Feb 19, 2019 at 11:55:22PM +0100, Andrea Parri wrote: > The comment should say "Sometimes" for the result. I queued both of these, thank you! Just to be clear "Maybe" is "don't care", so this patch is changing this litmus test from "LKMM can allow or forbid, at its option" to "LKMM must allow". Which should be fine, given that the test has absolutely no ordering. Thanx, Paul > Signed-off-by: Andrea Parri > Cc: Alan Stern > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Boqun Feng > Cc: Nicholas Piggin > Cc: David Howells > Cc: Jade Alglave > Cc: Luc Maranget > Cc: "Paul E. McKenney" > Cc: Akira Yokosawa > Cc: Daniel Lustig > --- > tools/memory-model/litmus-tests/MP+poonceonces.litmus | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/memory-model/litmus-tests/MP+poonceonces.litmus b/tools/memory-model/litmus-tests/MP+poonceonces.litmus > index b2b60b84fb9dc..172f0145301c5 100644 > --- a/tools/memory-model/litmus-tests/MP+poonceonces.litmus > +++ b/tools/memory-model/litmus-tests/MP+poonceonces.litmus > @@ -1,7 +1,7 @@ > C MP+poonceonces > > (* > - * Result: Maybe > + * Result: Sometimes > * > * Can the counter-intuitive message-passing outcome be prevented with > * no ordering at all? > -- > 2.7.4 >