linux-kernel - Re: Prototype patch for Linux-kernel memory model

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: <Pine.LNX.4.44L0.1712191105020.1429-100000@iolanthe.rowland.org>
Date:   Tue, 19 Dec 2017 11:05:44 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     afzal mohammed <afzal.mohd.ma@...il.com>
cc:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Peter Zijlstra <peterz@...radead.org>,
        <parri.andrea@...il.com>, <will.deacon@....com>,
        <boqun.feng@...il.com>, <npiggin@...il.com>, <dhowells@...hat.com>,
        <j.alglave@....ac.uk>, <luc.maranget@...ia.fr>,
        <linux-kernel@...r.kernel.org>, <elena.reshetova@...el.com>
Subject: Re: Prototype patch for Linux-kernel memory model

On Tue, 19 Dec 2017, afzal mohammed wrote:

> Hi,
> 
> A trivial & late (sorry) comment,
> 
> On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote:
> 
> > +THE HAPPENS-BEFORE RELATION: hb
> > +-------------------------------
> 
> > +Less trivial examples of prop all involve fences.  Unlike the simple
> > +examples above, they can require that some instructions are executed
> > +out of program order.  This next one should look familiar:
> > +
> > +	int buf = 0, flag = 0;
> > +
> > +	P0()
> > +	{
> > +		WRITE_ONCE(buf, 1);
> > +		smp_wmb();
> > +		WRITE_ONCE(flag, 1);
> > +	}
> > +
> > +	P1()
> > +	{
> > +		int r1;
> > +		int r2;
> > +
> > +		r1 = READ_ONCE(flag);
> > +		r2 = READ_ONCE(buf);
> > +	}
> > +
> > +This is the MP pattern again, with an smp_wmb() fence between the two
> > +stores.  If r1 = 1 and r2 = 0 at the end then there is a prop link
> > +from P1's second load to its first (backwards!).  The reason is
> > +similar to the previous examples: The value P1 loads from buf gets
> > +overwritten by P1's store to buf,
> 
>                   P0's store to buf
> 
> afzal

Thank you; I have applied the change.

Alan Stern