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 12:28:57 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Dmitry Vyukov <dvyukov@...gle.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:56:54AM -0700, Linus Torvalds wrote:
> 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.

Speaking as one of the ISO C people...  What exactly do you have in
mind when you say to just describe it to compiler people as "this is a
consume relationship"?

							Thanx, Paul