linux-kernel - Re: [PATCH] barriers: introduce smp_mb__release

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: <20150922163846.GU4029@linux.vnet.ibm.com>
Date:	Tue, 22 Sep 2015 09:38:46 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Will Deacon <will.deacon@....com>
Cc:	Boqun Feng <boqun.feng@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] barriers: introduce smp_mb__release_acquire and update
 documentation

On Tue, Sep 22, 2015 at 04:58:28PM +0100, Will Deacon wrote:
> Hi Paul,
> 
> On Tue, Sep 22, 2015 at 04:22:41PM +0100, Paul E. McKenney wrote:
> > On Mon, Sep 21, 2015 at 11:23:01PM +0100, Will Deacon wrote:
> > > On Mon, Sep 21, 2015 at 03:10:38PM +0100, Boqun Feng wrote:
> > > > On Mon, Sep 21, 2015 at 09:45:15PM +0800, Boqun Feng wrote:
> > > > > 
> > > > > Ah.. that's indeed an issue! for example:
> > > > > 
> > > > > CPU 0			CPU 1				CPU 2
> > > > > =====================	==========================	================
> > > > > {a = 0, b = 0, c = 0}
> > > > > r1 = READ_ONCE(a);	WRITE_ONCE(b, 1);		r3 = smp_load_acquire(&c);
> > > > > smp_rmb();		smp_store_release(&c, 1);	WRITE_ONCE(a, 1);
> > > > > r2 = READ_ONCE(b)
> > > > > 
> > > > > where r1 == 1 && r2 == 0 && r3 == 1 is actually not prohibitted, at
> > > > > least on POWER.
> > > > > 
> > > > 
> > > > Oops.. I use wrong litmus here.. so this is prohibitted on POWER. Sorry
> > > > for the misleading. How about the behavior of that on arm and arm64?
> > > 
> > > That explicit test is forbidden on arm/arm64 because of the smp_rmb(),
> > > but if you rewrite it as (LDAR is acquire, STLR is release):
> > > 
> > > 
> > >   {
> > >   0:X1=x; 0:X3=y;
> > >   1:X1=y; 1:X2=z;
> > >   2:X1=z; 2:X3=x;
> > >   }
> > >    P0           | P1           | P2                ;
> > >    LDAR W0,[X1] | MOV W0,#1    | LDAR W0,[X1]      ;
> > >    LDR W2,[X3]  | STR W0,[X1]  | MOV W2,#1         ;
> > >                 | STLR W0,[X2] | STR W2,[X3]       ;
> > > 
> > >   Observed
> > >       0:X0=1; 0:X2=0; 2:X0=1;
> > > 
> > > 
> > > then it is permitted on arm64. Note that herd currently claims that this
> > > is forbidden, but I'm talking to the authors about getting that fixed :)
> > 
> > But a pure store-release/load-acquire chain would be forbidden in
> > hardware as well as by herd, correct?
> 
> Yup, and since that's likely the common use-case, I think that's precisely
> the scenario where it makes sense for us to require transitivity in the
> kernel.

Agreed.  And again I believe that we need to err on the side of restricting
what the developer can expect.

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/