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:   Tue, 6 Jul 2021 10:00: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()


Sorry for the late reply, thread got snowed under :/

On Mon, Jun 21, 2021 at 06:37:57AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 21, 2021 at 09:28:02AM +0200, Peter Zijlstra wrote:
> > 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 :-)
> 
> I know that feeling!  ;-)
> 
> > > 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?
> 
> Because detection of that data race can provide valuable debugging help.

In that case, would not an explicit: data_debug(addr) call (implemented
by KASAN/KCSAN/whoever), which would report whatever knowledge they have
about that address, be even more useful?

Then you don't need to hope that there's a data race of sorts in order
to obtain said information.

That is; if you want information, explicitly asking for it seems *much*
better than hoping.