From: Andrea Parri <parri.andrea@gmail.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Alan Stern <stern@rowland.harvard.edu>,
Peter Zijlstra <peterz@infradead.org>,
will.deacon@arm.com, npiggin@gmail.com, dhowells@redhat.com,
j.alglave@ucl.ac.uk, luc.maranget@inria.fr,
linux-kernel@vger.kernel.org, elena.reshetova@intel.com
Subject: Re: Prototype patch for Linux-kernel memory model
Date: Mon, 20 Nov 2017 17:35:04 +0100 [thread overview]
Message-ID: <20171120163343.GA5842@andrea> (raw)
In-Reply-To: <20171117112746.GB6719@tardis>
On Fri, Nov 17, 2017 at 07:27:46PM +0800, Boqun Feng wrote:
> On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote:
> > On Tue, Nov 14, 2017 at 09:15:05AM -0800, Paul E. McKenney wrote:
> > > On Tue, Nov 14, 2017 at 10:19:21AM -0500, Alan Stern wrote:
> > > > On Tue, 14 Nov 2017, Peter Zijlstra wrote:
> > > >
> > > > > On Mon, Nov 13, 2017 at 10:40:31AM -0800, Paul E. McKenney wrote:
> > > > > > commit 82a1431549b4eae531e83298fd72cd0acea08540
> > > > > > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > > > > > Date: Mon Nov 13 10:30:07 2017 -0800
> > > > > >
> > > > > > tools: Automate memory-barriers.txt; provide Linux-kernel memory model
> > > > > >
> > > > > > There is some reason to believe that Documentation/memory-barriers.txt
> > > > > > could use some help, and a major purpose of this patch is to provide
> > > > > > that help in the form of a design-time tool that can produce all valid
> > > > > > executions of a small fragment of concurrent Linux-kernel code, which is
> > > > > > called a "litmus test". This tool's functionality is roughly similar to
> > > > > > a full state-space search. Please note that this is a design-time tool,
> > > > > > not useful for regression testing. However, we hope that the underlying
> > > > > > Linux-kernel memory model will be incorporated into other tools capable
> > > > > > of analyzing large bodies of code for regression-testing purposes.
> > > > > >
> > > > > > The main tool is herd7, together with the linux-kernel.bell,
> > > > > > linux-kernel.cat, linux-kernel.cfg, linux-kernel.def, and lock.cat files
> > > > > > added by this patch. The herd7 executable takes the other files as input,
> > > > > > and all of these files collectively define the Linux-kernel memory memory
> > > > > > model. A brief description of each of these other files is provided
> > > > > > in the README file. Although this tool does have its limitations,
> > > > > > which are documented in the README file, it does improve on the version
> > > > > > reported on in the LWN series (https://lwn.net/Articles/718628/ and
> > > > > > https://lwn.net/Articles/720550/) by supporting locking and arithmetic,
> > > > > > including a much wider variety of read-modify-write atomic operations.
> > > > > > Please note that herd7 is not part of this submission, but is freely
> > > > > > available from http://diy.inria.fr/sources/index.html (and via "git"
> > > > > > at https://github.com/herd/herdtools7).
> > > > > >
> > > > > > A second tool is klitmus7, which converts litmus tests to loadable
> > > > > > kernel modules for direct testing. As with herd7, the klitmus7
> > > > > > code is freely available from http://diy.inria.fr/sources/index.html
> > > > > > (and via "git" at https://github.com/herd/herdtools7).
> > > > > >
> > > > > > Of course, litmus tests are not always the best way to fully understand a
> > > > > > memory model, so this patch also includes Documentation/explanation.txt,
> > > > > > which describes the memory model in detail. In addition,
> > > > > > Documentation/recipes.txt provides example known-good and known-bad use
> > > > > > cases for those who prefer working by example.
> > > > > >
> > > > > > This patch also includes a few sample litmus tests, and a great many
> > > > > > more litmus tests are available at https://github.com/paulmckrcu/litmus.
> > > > > >
> > > > > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > > > > > Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
> > > > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > > > > Signed-off-by: Peter Zijlstra <peterz@infradead.org>
> > > > > > Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> > > > > > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > > > > > Signed-off-by: David Howells <dhowells@redhat.com>
> > > > > > Signed-off-by: Jade Alglave <j.alglave@ucl.ac.uk>
> > > > > > Signed-off-by: Luc Maranget <luc.maranget@inria.fr>
> > > > > > Signed-off-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > > > > > Cc: <linux-arch@vger.kernel.org>
> > > > >
> > > > > So I think that SoB chains like that are utter crap. I think you meant
> > > > > to have all but the one from you be an Ack or similar.
> > > >
> > > > That's right. Git doesn't understand the concept of multiple
> > > > authorship. Accepted practice is to have one Signed-off-by line and a
> > > > bunch of Acked-by or Reviewed-by tags.
> > > >
> > > > When there's a chain of Signed-off-by tags, it means the first person
> > > > was the author, who submitted it to the second person's tree, and it
> > > > went from there to the third person's tree, etc. (which would imply
> > > > multiple levels of maintainers and submaintainers).
> > >
> > > I could add a paragraph just before the Signed-off-by/Acked-by/etc.
> > > block describing the roles and contributions, convert the people who
> > > were directly involved to Reviewed-by and everyone else to Acked-by
> > > (unless they explicitly provided a Reviewed-by).
> > >
> > > Would that work, or does someone have a better approach?
> >
>
> How about using the shiny new "Co-Developed-by"?
>
> https://marc.info/?l=linux-kernel&m=151083859723653&w=2
This seems to be exactly what we were looking for/we needed. Altought
still undocumented in "mainline", the tag has already found some uses
in the past, and it appears in its commit log. I've just modified com-
mit-log.txt in the "memory-model" repo. to adopt this tag.
>
> Besides, as you know, I've been following and learning a lot from this
> model from maybe very beginning, and I have read throught the documents
> and cat files, and even got a chance to verify some RCU-involved code
> with Andrea using this model ;-) So feel free to add:
>
> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Added. Thanks,
Andrea
>
> Regards,
> Boqun
>
> > Hearing no objections, here is an updated prototype patch. Thank you
> > all for the review, comments, and updates!
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > commit 869b3c396eb908e3dfafbd75ed33421b3bcd50bf
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Date: Mon Nov 13 10:30:07 2017 -0800
> >
> > tools: Automate memory-barriers.txt; provide Linux-kernel memory model
> >
> > There is some reason to believe that Documentation/memory-barriers.txt
> > could use some help, and a major purpose of this patch is to provide
> > that help in the form of a design-time tool that can produce all valid
> > executions of a small fragment of concurrent Linux-kernel code, which is
> > called a "litmus test". This tool's functionality is roughly similar to
> > a full state-space search. Please note that this is a design-time tool,
> > not useful for regression testing. However, we hope that the underlying
> > Linux-kernel memory model will be incorporated into other tools capable
> > of analyzing large bodies of code for regression-testing purposes.
> >
> > The main tool is herd7, together with the linux-kernel.bell,
> > linux-kernel.cat, linux-kernel.cfg, linux-kernel.def, and lock.cat files
> > added by this patch. The herd7 executable takes the other files as input,
> > and all of these files collectively define the Linux-kernel memory memory
> > model. A brief description of each of these other files is provided
> > in the README file. Although this tool does have its limitations,
> > which are documented in the README file, it does improve on the version
> > reported on in the LWN series (https://lwn.net/Articles/718628/ and
> > https://lwn.net/Articles/720550/) by supporting locking and arithmetic,
> > including a much wider variety of read-modify-write atomic operations.
> > Please note that herd7 is not part of this submission, but is freely
> > available from http://diy.inria.fr/sources/index.html (and via "git"
> > at https://github.com/herd/herdtools7).
> >
> > A second tool is klitmus7, which converts litmus tests to loadable
> > kernel modules for direct testing. As with herd7, the klitmus7
> > code is freely available from http://diy.inria.fr/sources/index.html
> > (and via "git" at https://github.com/herd/herdtools7).
> >
> > Of course, litmus tests are not always the best way to fully understand a
> > memory model, so this patch also includes Documentation/explanation.txt,
> > which describes the memory model in detail. In addition,
> > Documentation/recipes.txt provides example known-good and known-bad use
> > cases for those who prefer working by example.
> >
> > This patch also includes a few sample litmus tests, and a great many
> > more litmus tests are available at https://github.com/paulmckrcu/litmus.
> >
> > This patch was the result of a most excellent collaboration founded
> > by Jade Alglave and also including Alan Stern, Andrea Parri, and Luc
> > Maranget. For more details on the history of this collaboration, please
> > refer to the Linux-kernel memory model presentations at 2016 LinuxCon EU,
> > 2016 Kernel Summit, 2016 Linux Plumbers Conference, 2017 linux.conf.au,
> > or 2017 Linux Plumbers Conference microconference.
> >
> > Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
> > Reviewed-by: Andrea Parri <parri.andrea@gmail.com>
> > Reviewed-by: Jade Alglave <j.alglave@ucl.ac.uk>
> > Reviewed-by: Luc Maranget <luc.maranget@inria.fr>
> > Signed-off-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > Acked-by: Will Deacon <will.deacon@arm.com>
> > Acked-by: Peter Zijlstra <peterz@infradead.org>
> > Acked-by: Boqun Feng <boqun.feng@gmail.com>
> > Acked-by: Nicholas Piggin <npiggin@gmail.com>
> > Acked-by: David Howells <dhowells@redhat.com>
> > Acked-by: "Reshetova, Elena" <elena.reshetova@intel.com>
> > Cc: <linux-arch@vger.kernel.org>
> >
> [...]
next prev parent reply other threads:[~2017-11-20 16:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-13 18:40 Prototype patch for Linux-kernel memory model Paul E. McKenney
2017-11-13 20:09 ` Alan Stern
2017-11-14 4:52 ` Paul E. McKenney
2017-11-14 7:59 ` Peter Zijlstra
2017-11-14 15:19 ` Alan Stern
2017-11-14 17:15 ` Paul E. McKenney
2017-11-15 16:37 ` Paul E. McKenney
2017-11-17 11:27 ` Boqun Feng
2017-11-20 16:35 ` Andrea Parri [this message]
2017-11-20 19:30 ` Paul E. McKenney
2017-12-19 8:36 ` afzal mohammed
2017-12-19 16:05 ` Alan Stern
2017-12-20 11:31 ` afzal mohammed
2017-12-20 16:45 ` Paul E. McKenney
2017-12-21 3:30 ` afzal mohammed
2017-12-21 16:15 ` Paul E. McKenney
2017-12-22 4:11 ` afzal mohammed
2017-12-23 6:14 ` afzal mohammed
2018-01-02 20:25 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171120163343.GA5842@andrea \
--to=parri.andrea@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=elena.reshetova@intel.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox