Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 8 Nov 2019 12:42:05 -0500 (EST)
From:   Alan Stern <stern@rowland.harvard.edu>
To:     Will Deacon <will@kernel.org>
cc:     linux-kernel@vger.kernel.org, Yunjae Lee <lyj7694@gmail.com>,
        SeongJae Park <sj38.park@gmail.com>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Josh Triplett <josh@joshtriplett.org>,
        Matt Turner <mattst88@gmail.com>,
        Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
        Richard Henderson <rth@twiddle.net>,
        Peter Zijlstra <peterz@infradead.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        "Michael S. Tsirkin" <mst@redhat.com>,
        Jason Wang <jasowang@redhat.com>,
        Arnd Bergmann <arnd@arndb.de>, Joe Perches <joe@perches.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        <linux-alpha@vger.kernel.org>,
        <virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH 10/13] tools/memory-model: Remove smp_read_barrier_depends()
 from informal doc
In-Reply-To: <20191108170120.22331-11-will@kernel.org>
Message-ID: <Pine.LNX.4.44L0.1911081241460.1498-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, 8 Nov 2019, Will Deacon wrote:

> 'smp_read_barrier_depends()' has gone the way of mmiowb() and so many
> esoteric memory barriers before it. Drop the two mentions of this
> deceased barrier from the LKMM informal explanation document.
> 
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>  .../Documentation/explanation.txt             | 26 +++++++++----------
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt
> index 488f11f6c588..3050bf67b8d0 100644
> --- a/tools/memory-model/Documentation/explanation.txt
> +++ b/tools/memory-model/Documentation/explanation.txt
> @@ -1118,12 +1118,10 @@ maintain at least the appearance of FIFO order.
>  In practice, this difficulty is solved by inserting a special fence
>  between P1's two loads when the kernel is compiled for the Alpha
>  architecture.  In fact, as of version 4.15, the kernel automatically
> -adds this fence (called smp_read_barrier_depends() and defined as
> -nothing at all on non-Alpha builds) after every READ_ONCE() and atomic
> -load.  The effect of the fence is to cause the CPU not to execute any
> -po-later instructions until after the local cache has finished
> -processing all the stores it has already received.  Thus, if the code
> -was changed to:
> +adds this fence after every READ_ONCE() and atomic load on Alpha.  The
> +effect of the fence is to cause the CPU not to execute any po-later
> +instructions until after the local cache has finished processing all
> +the stores it has already received.  Thus, if the code was changed to:
>  
>  	P1()
>  	{
> @@ -1142,14 +1140,14 @@ READ_ONCE() or another synchronization primitive rather than accessed
>  directly.
>  
>  The LKMM requires that smp_rmb(), acquire fences, and strong fences
> -share this property with smp_read_barrier_depends(): They do not allow
> -the CPU to execute any po-later instructions (or po-later loads in the
> -case of smp_rmb()) until all outstanding stores have been processed by
> -the local cache.  In the case of a strong fence, the CPU first has to
> -wait for all of its po-earlier stores to propagate to every other CPU
> -in the system; then it has to wait for the local cache to process all
> -the stores received as of that time -- not just the stores received
> -when the strong fence began.
> +share this property: They do not allow the CPU to execute any po-later
> +instructions (or po-later loads in the case of smp_rmb()) until all
> +outstanding stores have been processed by the local cache.  In the
> +case of a strong fence, the CPU first has to wait for all of its
> +po-earlier stores to propagate to every other CPU in the system; then
> +it has to wait for the local cache to process all the stores received
> +as of that time -- not just the stores received when the strong fence
> +began.
>  
>  And of course, none of this matters for any architecture other than
>  Alpha.

Acked-by: Alan Stern <stern@rowland.harvard.edu>