linux-kernel - Re: [PATCH 5/5] Documentation/memory-barriers: Fix typos

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: <20200131212349.GY2935@paulmck-ThinkPad-P72>
Date:   Fri, 31 Jan 2020 13:23:49 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     SeongJae Park <sj38.park@...il.com>
Cc:     corbet@....net, SeongJae Park <sjpark@...zon.de>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] Documentation/memory-barriers: Fix typos

On Fri, Jan 31, 2020 at 09:52:37PM +0100, SeongJae Park wrote:
> From: SeongJae Park <sjpark@...zon.de>
> 
> Signed-off-by: SeongJae Park <sjpark@...zon.de>

Good catches, queued, thank you!

But if Jon would rather take this:

Reviewed-by: Paul E. McKenney <paulmck@...nel.org>

							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 ec3b5865c1be..01ab5e22b670 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -185,7 +185,7 @@ As a further example, consider this sequence of events:
>  	===============	===============
>  	{ A == 1, B == 2, C == 3, P == &A, Q == &C }
>  	B = 4;		Q = P;
> -	P = &B		D = *Q;
> +	P = &B;		D = *Q;
>  
>  There is an obvious data dependency here, as the value loaded into D depends on
>  the address retrieved from P by CPU 2.  At the end of the sequence, any of the
> @@ -569,7 +569,7 @@ following sequence of events:
>  	{ A == 1, B == 2, C == 3, P == &A, Q == &C }
>  	B = 4;
>  	<write barrier>
> -	WRITE_ONCE(P, &B)
> +	WRITE_ONCE(P, &B);
>  			      Q = READ_ONCE(P);
>  			      D = *Q;
>  
> @@ -1721,7 +1721,7 @@ of optimizations:
>       and WRITE_ONCE() are more selective:  With READ_ONCE() and
>       WRITE_ONCE(), the compiler need only forget the contents of the
>       indicated memory locations, while with barrier() the compiler must
> -     discard the value of all memory locations that it has currented
> +     discard the value of all memory locations that it has currently
>       cached in any machine registers.  Of course, the compiler must also
>       respect the order in which the READ_ONCE()s and WRITE_ONCE()s occur,
>       though the CPU of course need not do so.
> @@ -1833,7 +1833,7 @@ Aside: In the case of data dependencies, the compiler would be expected
>  to issue the loads in the correct order (eg. `a[b]` would have to load
>  the value of b before loading a[b]), however there is no guarantee in
>  the C specification that the compiler may not speculate the value of b
> -(eg. is equal to 1) and load a before b (eg. tmp = a[1]; if (b != 1)
> +(eg. is equal to 1) and load a[b] before b (eg. tmp = a[1]; if (b != 1)
>  tmp = a[b]; ).  There is also the problem of a compiler reloading b after
>  having loaded a[b], thus having a newer copy of b than a[b].  A consensus
>  has not yet been reached about these problems, however the READ_ONCE()
> -- 
> 2.17.1
>