linux-kernel - Re: [PATCH] tools/memory-model: Provide extra ordering for unlock+lock pair on the same CPU

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]

Message-ID: <20210930181753.GH880162@paulmck-ThinkPad-P17-Gen-1>
Date:   Thu, 30 Sep 2021 11:17:53 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Boqun Feng <boqun.feng@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dan Lustig <dlustig@...dia.com>, Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Peter Anvin <hpa@...or.com>,
        Andrea Parri <parri.andrea@...il.com>,
        Ingo Molnar <mingo@...nel.org>,
        Vince Weaver <vincent.weaver@...ne.edu>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jiri Olsa <jolsa@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Stephane Eranian <eranian@...gle.com>, palmer@...belt.com,
        paul.walmsley@...ive.com, mpe@...erman.id.au
Subject: Re: [PATCH] tools/memory-model: Provide extra ordering for
 unlock+lock pair on the same CPU

On Thu, Sep 30, 2021 at 11:20:33AM -0400, Alan Stern wrote:
> On Thu, Sep 30, 2021 at 09:08:23PM +0800, Boqun Feng wrote:
> > A recent discussion[1] shows that we are in favor of strengthening the
> > ordering of unlock + lock on the same CPU: a unlock and a po-after lock
> > should provide the so-called RCtso ordering, that is a memory access S
> > po-before the unlock should be ordered against a memory access R
> > po-after the lock, unless S is a store and R is a load.
> > 
> > The strengthening meets programmers' expection that "sequence of two
> > locked regions to be ordered wrt each other" (from Linus), and can
> > reduce the mental burden when using locks. Therefore add it in LKMM.
> > 
> > [1]: https://lore.kernel.org/lkml/20210909185937.GA12379@rowland.harvard.edu/
> > 
> > Co-developed-by: Alan Stern <stern@...land.harvard.edu>
> > Signed-off-by: Alan Stern <stern@...land.harvard.edu>
> > Signed-off-by: Boqun Feng <boqun.feng@...il.com>
> > ---
> > Alan,
> > 
> > I added the "Co-developed-by" and "Signed-off-by" tags since most of the
> > work is done by you. Feel free to let me know if you want to change
> > anything.
> 
> It looks good to me.  However, do we really want to add these litmus
> tests to the kernel source, or would it be better to keep them with
> the thousands of other tests in Paul's archives?

Either way works for me.  But if they are referred to from within the
kernel, it is best to have them in the kernel source.  Which might be seen
as a reason to minimize referring to litmus tests from the kernel.  ;-)

							Thanx, Paul