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]

Date:   Wed, 20 Dec 2017 17:01:45 +0530
From:   afzal mohammed <afzal.mohd.ma@...il.com>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     Alan Stern <stern@...land.harvard.edu>,
        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

Hi,

Is this patch not destined to the HEAD of Torvalds ?, got that feeling
as this was in flight around merge window & have not yet made there.

On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote:

> diff --git a/tools/memory-model/Documentation/recipes.txt b/tools/memory-model/Documentation/recipes.txt

> +Taking off the training wheels
> +==============================
:
> +Release-acquire chains
> +----------------------
:
> +It is tempting to assume that CPU0()'s store to x is globally ordered
> +before CPU1()'s store to z, but this is not the case:
> +
> +	/* See Z6.0+pooncerelease+poacquirerelease+mbonceonce.litmus. */
> +	void CPU0(void)
> +	{
> +		WRITE_ONCE(x, 1);
> +		smp_store_release(&y, 1);
> +	}
> +
> +	void CPU1(void)
> +	{
> +		r1 = smp_load_acquire(y);
> +		smp_store_release(&z, 1);
> +	}
> +
> +	void CPU2(void)
> +	{
> +		WRITE_ONCE(z, 2);
> +		smp_mb();
> +		r2 = READ_ONCE(x);
> +	}
> +
> +One might hope that if the final value of r1 is 1 and the final value
> +of z is 2, then the final value of r2 must also be 1, but the opposite
> +outcome really is possible.

As there are 3 variables to have the values, perhaps, it might be
clearer to have instead of "the opposite.." - "the final value need
not be 1" or was that a read between the lines left as an exercise to
the idiots ;)

afzal


>  The reason, of course, is that in this
> +version, CPU2() is not part of the release-acquire chain.  This
> +situation is accounted for in the rules of thumb below.