linux-kernel - Re: data dependency naming inconsistency

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:   Thu, 14 Oct 2021 13:43:24 +0900
From:   Akira Yokosawa <akys@....so-net.ne.jp>
To:     mst@...hat.com
Cc:     linux-kernel@...r.kernel.org, paulmck@...ux.ibm.com,
        Akira Yokosawa <akiyks@...il.com>
Subject: Re: data dependency naming inconsistency

On Mon, 11 Oct 2021 07:07:08 -0400, Michael S. Tsirkin wrote:
> Hello Paul, all!

Hello Michael,

I thought Paul would respond soon, but looks like he has not
done so.
So, I'm trying to give some hint to your findings.

> I've been reading with interest Paul's posts about Rust interactions with LKMM
> https://paulmck.livejournal.com/63316.html
> and in particular it states:
> 		A data dependency involves a load whose return value directly or
> 	indirectly determine the value stored by a later store, which results in
> 	the load being ordered before the store.
> 
> This matches the perf book:
> 	A data dependency occurs when the value returned by
> 	a load instruction is used to compute the data stored by
> 	a later store instruction.

You might likely be aware, but these concern "data dependency",
not a _barrier_.

> 
> however, memory-barriers.txt states:
> 
>      A data dependency barrier is a partial ordering on interdependent loads
>      only; it is not required to have any effect on stores, independent loads
>      or overlapping loads.
> 
> It also says:
> 	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.

These concern the historic "data-dependency barrier", or
[smp_]read_barrier_depends(), which existed until Linux kernel v4.14.

> 
> so the result it the same: writes are ordered without a barrier,
> reads are ordered by a barrier.
> 
> However, it would seem that a bit more consistency in naming won't
> hurt.

So, I don't think the historic term of "data-dependency barrier"
can be changed.

I guess the right approach would be to further de-emphasize
"data-dependency barrier"/"data dependency barrier" in
memory-barriers.txt.

Rewrite by commit 8ca924aeb4f2 ("Documentation/barriers: Remove
references to [smp_]read_barrier_depends()") did some of such
changes, but it failed to update the introductory section of
"VARIETIES OF MEMORY BARRIER".
The part Michael quoted above belongs to it.
I don't think it has any merit keeping it around.

Also, there remain a couple of ascii-art diagrams concerning
<data dependency barrier> in the first part of "EXAMPLES OF MEMORY
BARRIER SEQUENCES" section, which, I think, can be removed as well.

Hope this helps clarify the circumstances.

Paul, what is your take on the naming of "data dependency"/
"data dependency barrier"?

        Thanks, Akira

> 
> Thanks,
> 
> -- 
> MST