On Mon, Nov 23, 2015 at 05:04:17PM -0500, Chris Metcalf wrote:
> In commit 2ecf810121c7 ("Documentation/memory-barriers.txt: Add
> needed ACCESS_ONCE() calls to memory-barriers.txt") the statement
> "Q = P" was converted to "ACCESS_ONCE(Q) = P". This should have
> been "Q = ACCESS_ONCE(P)". It later became "WRITE_ONCE(Q, P)".
> This doesn't match the following text, which is "Q = LOAD P".
> Change the statement to be "Q = READ_ONCE(P)".
>
> Signed-off-by: Chris Metcalf <[email protected]>
Good eyes! Queued for v4.5.
Thanx, Paul
> ---
> Documentation/memory-barriers.txt | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/memory-barriers.txt
> b/Documentation/memory-barriers.txt
> index aef9487303d0..85304ebd187c 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -194,7 +194,7 @@ There are some minimal guarantees that may be expected of
> a CPU:
> (*) On any given CPU, dependent memory accesses will be issued in order,
> with
> respect to itself. This means that for:
>
> - WRITE_ONCE(Q, P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
> + Q = READ_ONCE(P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
>
> the CPU will issue the following memory operations:
>
> @@ -202,9 +202,9 @@ There are some minimal guarantees that may be expected of
> a CPU:
>
> and always in that order. On most systems, smp_read_barrier_depends()
> does nothing, but it is required for DEC Alpha. The READ_ONCE()
> - and WRITE_ONCE() are required to prevent compiler mischief. Please
> - note that you should normally use something like rcu_dereference()
> - instead of open-coding smp_read_barrier_depends().
> + is required to prevent compiler mischief. Please note that you
> + should normally use something like rcu_dereference() instead of
> + open-coding smp_read_barrier_depends().
>
> (*) Overlapping loads and stores within a particular CPU will appear to be
> ordered within that CPU. This means that for:
> --
> 2.1.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
