linux-kernel - Re: RCU vs data

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:   Mon, 21 Jun 2021 09:28:02 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Marco Elver <elver@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: RCU vs data_race()

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?