linux-kernel - Re: LKMM litmus test for Roman Penyaev's rcu-rr

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:   Mon, 4 Jun 2018 10:17:47 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        <andrea.parri@...rulasolutions.com>,
        Will Deacon <will.deacon@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Nick Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        Luc Maranget <luc.maranget@...ia.fr>,
        Akira Yokosawa <akiyks@...il.com>,
        Ingo Molnar <mingo@...nel.org>,
        Roman Pen <roman.penyaev@...fitbricks.com>
Subject: Re: LKMM litmus test for Roman Penyaev's rcu-rr

On Sat, 2 Jun 2018, Paul E. McKenney wrote:

> One crude but effective workaround is to replicate the code following the
> "if" statement into both legs of the "if" statement.  This has the effect
> of extending the control dependency to cover all of the code that used to
> follow the "if" statement, leveraging herd's current limited knowledge of
> compiler optimization.  This workaround would of course be hopeless for
> general Linux-kernel code, but should be at least semi-acceptable for the
> very small snippets of code that can be accommodated within litmus tests.
> 
> Please see the litmus test shown below, which uses this workaround,
> allowing the smp_store_release() to be downgraded to WRITE_ONCE().
> 
> Given this workaround, crude though it might be, I believe that we can
> take a more measured approach to identifying a longer-term solution.
> 
> Thoughts?

Yes, this works, although it is clearly just a stopgap.  And obviously
it can't be applied in situations where one of the legs of the "if"  
statement contains a non-trivial branch.

In the long run, I don't think this problem is solvable.  At least, not 
for all cases.  It requires too much guesswork about what optimizations 
a compiler might do.

Alan