linux-kernel - Re: Prototype patch for Linux-kernel memory model

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Nov 2017 10:19:21 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Peter Zijlstra <peterz@...radead.org>
cc:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        <parri.andrea@...il.com>, <will.deacon@....com>,
        <boqun.feng@...il.com>, <npiggin@...il.com>, <dhowells@...hat.com>,
        <j.alglave@....ac.uk>, <luc.maranget@...ia.fr>,
        <linux-kernel@...r.kernel.org>, <elena.reshetova@...el.com>
Subject: Re: Prototype patch for Linux-kernel memory model

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@...ux.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@...land.harvard.edu>
> >     Signed-off-by: Andrea Parri <parri.andrea@...il.com>
> >     Signed-off-by: Will Deacon <will.deacon@....com>
> >     Signed-off-by: Peter Zijlstra <peterz@...radead.org>
> >     Signed-off-by: Boqun Feng <boqun.feng@...il.com>
> >     Signed-off-by: Nicholas Piggin <npiggin@...il.com>
> >     Signed-off-by: David Howells <dhowells@...hat.com>
> >     Signed-off-by: Jade Alglave <j.alglave@....ac.uk>
> >     Signed-off-by: Luc Maranget <luc.maranget@...ia.fr>
> >     Signed-off-by: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> >     Cc: <linux-arch@...r.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).

Alan