Re: [PATCH RFC tip/core/rcu 12/15] lib/assoc_array: Remove smp_read_barrier_depends()

[Paul E. McKenney]

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@xxxxxxxxxx> 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