From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753886AbdKQL0T (ORCPT ); Fri, 17 Nov 2017 06:26:19 -0500 Received: from mail-qt0-f196.google.com ([209.85.216.196]:46960 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753778AbdKQL0K (ORCPT ); Fri, 17 Nov 2017 06:26:10 -0500 X-Google-Smtp-Source: AGs4zMaLUrTRdbBX3vFAL9t00xflQoxTS46GMhBb327xhMQf3cu5Xcf34ZSY4YSlihL3XBxuwnRyhQ== X-ME-Sender: Date: Fri, 17 Nov 2017 19:27:46 +0800 From: Boqun Feng To: "Paul E. McKenney" Cc: Alan Stern , Peter Zijlstra , parri.andrea@gmail.com, 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 Message-ID: <20171117112746.GB6719@tardis> References: <20171114075925.apzztfksn4f4y5ue@hirez.programming.kicks-ass.net> <20171114171505.GS3624@linux.vnet.ibm.com> <20171115163749.GA8555@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: <20171115163749.GA8555@linux.vnet.ibm.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > >=20 > > > > On Mon, Nov 13, 2017 at 10:40:31AM -0800, Paul E. McKenney wrote: > > > > > commit 82a1431549b4eae531e83298fd72cd0acea08540 > > > > > Author: Paul E. McKenney > > > > > Date: Mon Nov 13 10:30:07 2017 -0800 > > > > >=20 > > > > > tools: Automate memory-barriers.txt; provide Linux-kernel mem= ory model > > > > > =20 > > > > > There is some reason to believe that Documentation/memory-bar= riers.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 cod= e, 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 too= ls capable > > > > > of analyzing large bodies of code for regression-testing purp= oses. > > > > > =20 > > > > > The main tool is herd7, together with the linux-kernel.bell, > > > > > linux-kernel.cat, linux-kernel.cfg, linux-kernel.def, and loc= k.cat files > > > > > added by this patch. The herd7 executable takes the other fi= les as input, > > > > > and all of these files collectively define the Linux-kernel m= emory memory > > > > > model. A brief description of each of these other files is p= rovided > > > > > in the README file. Although this tool does have its limitat= ions, > > > > > which are documented in the README file, it does improve on t= he version > > > > > reported on in the LWN series (https://lwn.net/Articles/71862= 8/ and > > > > > https://lwn.net/Articles/720550/) by supporting locking and a= rithmetic, > > > > > including a much wider variety of read-modify-write atomic op= erations. > > > > > Please note that herd7 is not part of this submission, but is= freely > > > > > available from http://diy.inria.fr/sources/index.html (and vi= a "git" > > > > > at https://github.com/herd/herdtools7). > > > > > =20 > > > > > A second tool is klitmus7, which converts litmus tests to loa= dable > > > > > kernel modules for direct testing. As with herd7, the klitmu= s7 > > > > > code is freely available from http://diy.inria.fr/sources/ind= ex.html > > > > > (and via "git" at https://github.com/herd/herdtools7). > > > > > =20 > > > > > Of course, litmus tests are not always the best way to fully = understand a > > > > > memory model, so this patch also includes Documentation/expla= nation.txt, > > > > > which describes the memory model in detail. In addition, > > > > > Documentation/recipes.txt provides example known-good and kno= wn-bad use > > > > > cases for those who prefer working by example. > > > > > =20 > > > > > This patch also includes a few sample litmus tests, and a gre= at many > > > > > more litmus tests are available at https://github.com/paulmck= rcu/litmus. > > > > > =20 > > > > > Signed-off-by: Alan Stern > > > > > Signed-off-by: Andrea Parri > > > > > Signed-off-by: Will Deacon > > > > > Signed-off-by: Peter Zijlstra > > > > > Signed-off-by: Boqun Feng > > > > > Signed-off-by: Nicholas Piggin > > > > > Signed-off-by: David Howells > > > > > Signed-off-by: Jade Alglave > > > > > Signed-off-by: Luc Maranget > > > > > Signed-off-by: "Paul E. McKenney" > > > > > Cc: > > > >=20 > > > > So I think that SoB chains like that are utter crap. I think you me= ant > > > > to have all but the one from you be an Ack or similar. > > >=20 > > > 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. > > >=20 > > > When there's a chain of Signed-off-by tags, it means the first person= =20 > > > was the author, who submitted it to the second person's tree, and it= =20 > > > went from there to the third person's tree, etc. (which would imply= =20 > > > multiple levels of maintainers and submaintainers). > >=20 > > 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). > >=20 > > Would that work, or does someone have a better approach? >=20 How about using the shiny new "Co-Developed-by"? https://marc.info/?l=3Dlinux-kernel&m=3D151083859723653&w=3D2 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 Regards, Boqun > Hearing no objections, here is an updated prototype patch. Thank you > all for the review, comments, and updates! >=20 > Thanx, Paul >=20 > ------------------------------------------------------------------------ >=20 > commit 869b3c396eb908e3dfafbd75ed33421b3bcd50bf > Author: Paul E. McKenney > Date: Mon Nov 13 10:30:07 2017 -0800 >=20 > tools: Automate memory-barriers.txt; provide Linux-kernel memory model > =20 > 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 to= ol, > not useful for regression testing. However, we hope that the underly= ing > Linux-kernel memory model will be incorporated into other tools capab= le > of analyzing large bodies of code for regression-testing purposes. > =20 > The main tool is herd7, together with the linux-kernel.bell, > linux-kernel.cat, linux-kernel.cfg, linux-kernel.def, and lock.cat fi= les > added by this patch. The herd7 executable takes the other files as i= nput, > and all of these files collectively define the Linux-kernel memory me= mory > 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 versi= on > reported on in the LWN series (https://lwn.net/Articles/718628/ and > https://lwn.net/Articles/720550/) by supporting locking and arithmeti= c, > 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). > =20 > 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). > =20 > Of course, litmus tests are not always the best way to fully understa= nd a > memory model, so this patch also includes Documentation/explanation.t= xt, > which describes the memory model in detail. In addition, > Documentation/recipes.txt provides example known-good and known-bad u= se > cases for those who prefer working by example. > =20 > This patch also includes a few sample litmus tests, and a great many > more litmus tests are available at https://github.com/paulmckrcu/litm= us. > =20 > 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, ple= ase > refer to the Linux-kernel memory model presentations at 2016 LinuxCon= EU, > 2016 Kernel Summit, 2016 Linux Plumbers Conference, 2017 linux.conf.a= u, > or 2017 Linux Plumbers Conference microconference. > =20 > Reviewed-by: Alan Stern > Reviewed-by: Andrea Parri > Reviewed-by: Jade Alglave > Reviewed-by: Luc Maranget > Signed-off-by: "Paul E. McKenney" > Acked-by: Will Deacon > Acked-by: Peter Zijlstra > Acked-by: Boqun Feng > Acked-by: Nicholas Piggin > Acked-by: David Howells > Acked-by: "Reshetova, Elena" > Cc: >=20 [...] --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAloOx68ACgkQSXnow7UH +rjfIAgArUQohVrkxA9PNR8+q6MUP+ViJ9FDMfaOM7uXBoWhRwT2adVHJKPlj4S0 g9+N/9TkkN4AUSEPYrN7/DlhfRYbSAeE3hV9M3g49oLKYoCt9AGasjrHItOYYvjJ Tx1hQsgr5uRA3jqLnPW4igMft+3SbiNb+uWk8e0YuJwUycSh0rRJ8XNMqcDuOjGl 31GU95yzSoV1QIKVuOZyv58ZdRbfzFUtnXThy/5CciDEAPJgsik7MZ7sG9JRtOcw v1JDvm6hNJyuWhNXmo4FXLx/CZnayHha21jpZVjfp+jvuClJf3TCkymTbZBerv1T 59VdNe/0tQkEdin7CVIemF6BRUSLeg== =Z/KA -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb--