linux-kernel - Re: Current LKMM patch disposition

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] [day] [month] [year] [list]

Message-ID: <20230219080921.GG2948950@paulmck-ThinkPad-P17-Gen-1>
Date:   Sun, 19 Feb 2023 00:09:21 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     Alan Stern <stern@...land.harvard.edu>,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        kernel-team@...a.com, mingo@...nel.org, parri.andrea@...il.com,
        will@...nel.org, peterz@...radead.org, boqun.feng@...il.com,
        npiggin@...il.com, dhowells@...hat.com, j.alglave@....ac.uk,
        luc.maranget@...ia.fr, akiyks@...il.com
Subject: Re: Current LKMM patch disposition

On Sat, Feb 18, 2023 at 10:20:39PM -0500, Joel Fernandes wrote:
> On Sat, Feb 18, 2023 at 2:21 PM Paul E. McKenney <paulmck@...nel.org> wrote:
> >
> > On Sat, Feb 18, 2023 at 01:13:59AM -0500, Joel Fernandes wrote:
> > > Hi Alan,
> > >
> > > On Sat, Feb 11, 2023 at 9:59 PM Alan Stern <stern@...land.harvard.edu> wrote:
> > > >
> > > [...]
> > > >
> > > > Would you like to post a few examples showing some of the most difficult
> > > > points you encountered?  Maybe explanation.txt can be improved.
> > >
> > > One additional feedback I wanted to mention, regarding this paragraph
> > > under "WARNING":
> > > ===========
> > > The protections provided by READ_ONCE(), WRITE_ONCE(), and others are
> > > not perfect; and under some circumstances it is possible for the
> > > compiler to undermine the memory model. Here is an example. Suppose
> > > both branches of an "if" statement store the same value to the same
> > > location:
> > > r1 = READ_ONCE(x);
> > > if (r1) {
> > > WRITE_ONCE(y, 2);
> > > ... /* do something */
> > > } else {
> > > WRITE_ONCE(y, 2);
> > > ... /* do something else */
> > > }
> > > ===========
> > >
> > > I tried lots of different compilers with varying degrees of
> > > optimization, in all cases I find that the conditional instruction
> > > always appears in program order before the stores inside the body of
> > > the conditional. So I am not sure if this is really a valid concern on
> > > current compilers, if not - could you provide an example of a compiler
> > > and options that cause it?
> > >
> > > In any case, if it is a theoretical concern, it could be clarified
> > > that this is a theoretical possibility in the text.  And if it is a
> > > real/practical concern, then it could be mentioned the specific
> > > compiler/arch this was seen in.
> >
> > I could be misremembering, but I believe that this reordering has been
> > seen in the past.
> >
> 
> Thank you! And I also confirmed putting a barrier() in the branch
> body, also "cures" the optimization... I did not know compilers
> optimize so aggressively..

And the compilers are just getting started...  :-/

							Thanx, Paul