Re: RCU vs data_race()

[Peter Zijlstra]

On Sun, Jun 20, 2021 at 02:01:27PM -0700, Paul E. McKenney wrote:
> On Sun, Jun 20, 2021 at 09:14:28PM +0200, Peter Zijlstra wrote:

> > I don't buy that argument. pr_err() (or worse) is not supposed to
> > happen, ever. If it does, *that* is a far worse condition that any data
> > race possibly found by kcsan.
> > 
> > So the only way the pr_err() expression itself can lead to kcsan
> > determining a data-race, if something far worse triggered the pr_err()
> > itself.
> 
> Earlier, you said pr_warn().  Above, I said pr_*().  Now you say
> pr_err().  But OK...

Same, thing.. also Sundays aren't great for details it seems :-)

> Let's take for example the pr_err() in __call_rcu(), that is, the
> double-free diagnostic.  A KCSAN warning on the unmarked load from
> head->func could give valuable information on the whereabouts of the
> other code interfering with the callback.  Blanket disabling of KCSAN
> across all pr_err() calls (let alone all pr_*() calls) would be the
> opposite of helpful.

I'm confused. That pr_err() should never happen in a correct program. If
it happens, fix it and any data race as a consequence of that pr_err()
no longer exists either.

I fundementally don't see the relevance of a possible data race from a
statement that should never happen in a correct program to begin with.

Why do you think otherwise?

> > You've lost me on the schedule thing, what?
> 
> The definition of schedule_timeout_interruptible() is in part of the
> kernel that uses much looser KCSAN checking.  Thus there are some
> KCSAN warnings from RCU involving schedule_timeout_interruptible().
> But at least some of these warnings are for conflicting writes, which
> many parts of the kernel suppress KCSAN warnings for.

You've lost me again.. schedule_timeout_interruptible() doesn't do
writes to rcu state, does it? So how can there be problems?