[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200512141944.GC2869@paulmck-ThinkPad-P72>
Date: Tue, 12 May 2020 07:19:44 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Joel Fernandes <joel@...lfernandes.org>
Cc: Akira Yokosawa <akiyks@...il.com>,
Boqun Feng <boqun.feng@...il.com>,
linux-kernel@...r.kernel.org, vpillai@...italocean.com,
Jonathan Corbet <corbet@....net>,
Alan Stern <stern@...land.harvard.edu>,
Andrea Parri <parri.andrea@...il.com>,
Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Nicholas Piggin <npiggin@...il.com>,
David Howells <dhowells@...hat.com>,
Jade Alglave <j.alglave@....ac.uk>,
Luc Maranget <luc.maranget@...ia.fr>,
Daniel Lustig <dlustig@...dia.com>, linux-doc@...r.kernel.org
Subject: Re: [PATCH 0/3] tools/memory-model, Documentation/litmus-test: Sort
out location of litmus test and README
On Tue, May 12, 2020 at 08:19:36AM -0400, Joel Fernandes wrote:
> On Tue, May 12, 2020 at 08:50:45PM +0900, Akira Yokosawa wrote:
> [...]
> > > I think on top of this patch, I'd like to add a reference to the to the
> > > litmus test in tools/memory-model/ from Documentation/rcu/.
> >
> > Sounds reasonable to me. But for most people, it never changes its location.
> > Please find inline comments below.
> >
> > >
> > > Just to mention my rationale for Documentation/litmus-tests/rcu/, I was
> > > basically looking for a central place for RCU related litmus tests in the
> > > kernel sources and the idea of this new directory came up.
> > >
> > > For Akira's series,
> > > Acked-by: Joel Fernandes (Google) <joel@...lfernandes.org>
> >
> > Thank you!
> >
> > >
> > > And could we add the following patch on top of Akira's series so we still
> > > maintain a reference to the moved RCU test?>
> > > ---8<-----------------------
> > >
> > > From 52fdb57551cc769d8bd690f4f2b22de36ddece99 Mon Sep 17 00:00:00 2001
> > > From: "Joel Fernandes (Google)" <joel@...lfernandes.org>
> > > Date: Mon, 11 May 2020 22:06:46 -0400
> > > Subject: [PATCH] docs: litmus-tests: Clarify about the RCU pre-initialization
> > > test
> > >
> > > Since this test was moved to tools/memory-model/, make sure that it is
> > > at least referenced from Documentation/litmus-tests/'s README.
> > >
> > > Signed-off-by: Joel Fernandes (Google) <joel@...lfernandes.org>
> > > ---
> > > Documentation/litmus-tests/README | 6 ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README
> > > index ac0b270b456c1..53f09e74734a4 100644
> > > --- a/Documentation/litmus-tests/README
> > > +++ b/Documentation/litmus-tests/README
> > > @@ -11,7 +11,6 @@ tools/memory-model/README.
> > >
> > > atomic (/atomic derectory)
> > > --------------------------
> > > -
> > > Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus
> > > Test that an atomic RMW followed by a smp_mb__after_atomic() is
> > > stronger than a normal acquire: both the read and write parts of
> > > @@ -23,8 +22,11 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus
> > >
> > > RCU (/rcu directory)
> > > --------------------
> > > -
> >
> > I loosely followed the convention of ReST documents in putting these empty
> > lines. But I don't mind if they are removed.
> >
> > > RCU+sync+read.litmus
> > > RCU+sync+free.litmus
> > > Both the above litmus tests demonstrate the RCU grace period guarantee
> > > that an RCU read-side critical section can never span a grace period.
> > > +
> > > +MP+onceassign+derefonce.litmus (moved to tools/memory-model/litmus-tests/)
> >
> > As I said above, for those who don't follow developments in the lkmm branch,
> > MP+onceassign+derefonce.litmus stays in tools/memory-model/litmus-tests/.
> > So,
> >
> > +MP+onceassign+derefonce.litmus (under tools/memory-model/litmus-tests/)
> >
> > looks better to me.
>
> Yes it stays under tools/.. but is referenced here. Sounds like you agree and
> the only change from my follow-up patch that you want is to change "moved to"
> to "under".
>
> If so, Paul do you mind applying my patch and fixing this up? Or do you want
> to apply Akira's 3-patch series first and then have me send you another one
> on top?
Let's get something that you, Akira, and Alan are good with, then I will
apply that, either on top of or in place of the current commits (just
tell me which).
Thanx, Paul
Powered by blists - more mailing lists