linux-kernel - Re: [PATCH v2 0/4] atomic: Fixes to smp_mb__{before,after}

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190831100242.xhbgaodzbuqj5axy@pburton-laptop>
Date:   Sat, 31 Aug 2019 10:02:47 +0000
From:   Paul Burton <paul.burton@...s.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     "stern@...land.harvard.edu" <stern@...land.harvard.edu>,
        "akiyks@...il.com" <akiyks@...il.com>,
        "andrea.parri@...rulasolutions.com" 
        <andrea.parri@...rulasolutions.com>,
        "boqun.feng@...il.com" <boqun.feng@...il.com>,
        "dlustig@...dia.com" <dlustig@...dia.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "j.alglave@....ac.uk" <j.alglave@....ac.uk>,
        "luc.maranget@...ia.fr" <luc.maranget@...ia.fr>,
        "npiggin@...il.com" <npiggin@...il.com>,
        "paulmck@...ux.ibm.com" <paulmck@...ux.ibm.com>,
        "will.deacon@....com" <will.deacon@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2 0/4] atomic: Fixes to smp_mb__{before,after}_atomic()
 and mips.

Hi Peter,

On Sat, Aug 31, 2019 at 11:00:55AM +0200, Peter Zijlstra wrote:
> On Thu, Jun 13, 2019 at 03:43:17PM +0200, Peter Zijlstra wrote:
> > Hi,
> > 
> > This all started when Andrea Parri found a 'surprising' behaviour for x86:
> > 
> >   http://lkml.kernel.org/r/20190418125412.GA10817@andrea
> > 
> > Basically we fail for:
> > 
> > 	*x = 1;
> > 	atomic_inc(u);
> > 	smp_mb__after_atomic();
> > 	r0 = *y;
> > 
> > Because, while the atomic_inc() implies memory order, it
> > (surprisingly) does not provide a compiler barrier. This then allows
> > the compiler to re-order like so:
> > 
> > 	atomic_inc(u);
> > 	*x = 1;
> > 	smp_mb__after_atomic();
> > 	r0 = *y;
> > 
> > Which the CPU is then allowed to re-order (under TSO rules) like:
> > 
> > 	atomic_inc(u);
> > 	r0 = *y;
> > 	*x = 1;
> > 
> > And this very much was not intended.
> > 
> > This had me audit all the (strong) architectures that had weak
> > smp_mb__{before,after}_atomic: ia64, mips, sparc, s390, x86, xtensa.
> > 
> > Of those, only x86 and mips were affected. Looking at MIPS to solve this, led
> > to the other MIPS patches.
> > 
> > All these patches have been through 0day for quite a while.
> > 
> > Paul, how do you want to route the MIPS bits?
> 
> Paul; afaict the MIPS patches still apply (ie. they've not made their
> way into Linus' tree yet).
> 
> I thought you were going to take them?

My apologies, between the linux-mips mailing list not being copied (so
this didn't end up in patchwork) and my being away for my father's
funeral this fell through the cracks.

I'll go apply them to mips-next for v5.4.

Thanks for following up again,

    Paul