linux-kernel - Re: [PATCH RFC tip/core/rcu 12/15] lib/assoc_array: Remove smp_read_barrier

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:   Wed, 11 Oct 2017 11:56:54 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Paul McKenney <paulmck@...ux.vnet.ibm.com>,
        Peter Zijlstra <peterz@...radead.org>,
        David Howells <dhowells@...hat.com>,
        Will Deacon <will.deacon@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        Alexander Kuleshov <kuleshovmail@...il.com>
Subject: Re: [PATCH RFC tip/core/rcu 12/15] lib/assoc_array: Remove smp_read_barrier_depends()

On Wed, Oct 11, 2017 at 11:43 AM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> A long thread and I lost track somewhat, but, yes, from KTSAN (data
> race detector) point of view we will need a way to understand when
> things are ordered due to data and control dependencies
> (i.e.effectively acquire but only wrt the dependent stuff).
> There is a logic level and physical level, it's perfectly fine if on
> physical level all these _DEP/_CTRL variants are no-op (the same as
> READ_ONCE, at least on todays archs with todays compilers). But on
> logical level they represent a well defined, meaningful thing.

No, they do not.

Do you believe in fairies and Santa Claus?

Because quite frankly, the likelihood of either of those being true is
_way_ higher than the likelihood of any normal human ever getting
those things right.

So asking a programmer to annotate whether two memory accesses have a
data dependency or a control dependency is completely inappropriate.
You won't get people understanding it to begin with, much less then
figure out subtle things like whether a control dependency is an
actual branch, or might be turned into a data dependency through
select, or whatever.

We've had really smart people who wrote core code that couldn't get it
right, and that weren't sure if a control dependency was really
guaranteed or not.

That is *exactly* the kinds of thing that _automation_ should handle.
Not some human. Figure the data/control dependencies out from the
code, not from some logical level.

I saw the contortions that the ISO C people tried to go through just
to describe control and data dependencies. It was awful.  It should
have never been described on that kind of level to begin with, when it
would have been much easier to just describe it to compiler people as
"this is a consume relationship". The same rules apply here. Don't
make it about some high-level thing and humans annontating things.
Make it about the actual generated code.

                Linus