[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170703130703.GD1573@arm.com>
Date: Mon, 3 Jul 2017 14:07:03 +0100
From: Will Deacon <will.deacon@....com>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, ldr709@...il.com,
dhowells@...hat.com, peterz@...radead.org, corbet@....net,
stern@...land.harvard.edu, parri.andrea@...il.com,
j.alglave@....ac.uk, luc.maranget@...ia.fr
Subject: Re: [PATCH] doc: Update memory-barriers.txt for read-to-write
dependencies
Hi Paul,
On Fri, Jun 30, 2017 at 04:28:10PM -0700, Paul E. McKenney wrote:
> The memory-barriers.txt document contains an obsolete passage stating that
> smp_read_barrier_depends() is required to force ordering for read-to-write
> dependencies. We now know that this is not required, even for DEC Alpha.
> This commit therefore updates this passage to state that read-to-write
> dependencies are respected even without smp_read_barrier_depends().
>
> Reported-by: Lance Roy <ldr709@...il.com>
> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> Cc: David Howells <dhowells@...hat.com>
> Cc: Will Deacon <will.deacon@....com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Jonathan Corbet <corbet@....net>
> Cc: Alan Stern <stern@...land.harvard.edu>
> Cc: Andrea Parri <parri.andrea@...il.com>
> Cc: Jade Alglave <j.alglave@....ac.uk>
> Cc: Luc Maranget <luc.maranget@...ia.fr>
>
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 9d5e0f853f08..a8a91b9d5a1b 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -594,7 +594,10 @@ between the address load and the data load:
> This enforces the occurrence of one of the two implications, and prevents the
> third possibility from arising.
>
> -A data-dependency barrier must also order against dependent writes:
> +A data-dependency barrier is not required to order dependent writes
> +because the CPUs that the Linux kernel supports don't do writes until
> +they are certain (1) that the write will actually happen, (2) of the
> +location of the write, and (3) of the value to be written.
Might be worth mentioning that you have to careful with the compiler here,
and pointing to the section on "Control dependencies" so that people don't
just take these three points as guarantees in isolation.
>
> CPU 1 CPU 2
> =============== ===============
> @@ -603,19 +606,19 @@ A data-dependency barrier must also order against dependent writes:
> <write barrier>
> WRITE_ONCE(P, &B);
> Q = READ_ONCE(P);
> - <data dependency barrier>
> *Q = 5;
Do we want that write to Q to be a WRITE_ONCE? Again, the control
dependencies section does call this out.
Will
Powered by blists - more mailing lists