archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <>
To: Marco Elver <>,
	Naresh Kamboju <>
Cc: open list <>,
	kasan-dev <>,,,
	Peter Zijlstra <>,
	"Paul E. McKenney" <>,
	Ingo Molnar <>,, Arnd Bergmann <>
Subject: Re: BUG: KCSAN: data-race in tick_nohz_next_event / tick_nohz_stop_tick
Date: Sat, 05 Dec 2020 19:18:28 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Dec 04 2020 at 20:53, Marco Elver wrote:
> On Fri, 4 Dec 2020 at 20:04, Naresh Kamboju <> wrote:
>> LKFT started testing KCSAN enabled kernel from the linux next tree.
>> Here we have found BUG: KCSAN: data-race in tick_nohz_next_event /
>> tick_nohz_stop_tick
> Thank you for looking into KCSAN. Would it be possible to collect
> these reports in a moderation queue for now?

Yes please. This is the forth or fifth incarnation of report for that
data race in the tick code and I just did not come around to work on it.

> I'm currently trying to work out a strategy on how to best proceed
> with all the data races in the kernel. We do know there are plenty. On

I think having a central point where the reports are collected, i.e. a
moderation queue, is a good start. Reports like the one at hand should
stick out because they should reproduce pretty instantanious as it's an
intentional one and on NOHZ=y machines where CPUs are not fully loaded
its hard not to detect it :)

> The report below looks to be of type (A). Generally, the best strategy
> for resolving these is to send a patch, and not a report. However, be
> aware that sometimes it is really quite difficult to say if we're
> looking at a type (A) or (B) issue, in which case it may still be fair
> to send a report and briefly describe what you think is happening
> (because that'll increase the likelihood of getting a response). I
> recommend also reading "Developer/Maintainer data-race strategies" in
> -- specifically note "[...] you
> should not respond to KCSAN reports by mindlessly adding READ_ONCE(),
> data_race(), and WRITE_ONCE(). Instead, a patch addressing a KCSAN
> report must clearly identify the fix's approach and why that approach
> is appropriate."

Yes. I've seen a fair amount of 'Fix KCSAN warnings' patches which just
slap READ/WRITE_ONCE() all over the place to shut it up without any
justification. Most of them ended in limbo when asking for that

But the problem is that it is not necessarily trivial to understand code
when there are intentional data races without a lot of comments - guilty
as charged in this case. I actually felt so guilty that I sat down and
annotated and documented it now. Took me quite some time to comment all
the racy reads correctly as I really had to think about each of them
carefully again.

OTOH, in general it's a good exercise for reporters to do such analysis
and maintainers are happy to help when the analysis is not entirely
correct or comes to the wrong conclusion, e.g. assuming type B when it's
actually A. That's way better than just reports or mechanical "paper
over it" patches.

Just getting the reports over and over is not going to solve anything
because as in this case there is always more important stuff to do and
to the people familiar with the code it's clear that it's A and
therefore not urgent.

But that causes the problem that the A types are staying around for a
long time and blend over the B/C issues which are the real interesting

> This report should have line numbers, otherwise it's impossible to say
> which accesses are racing.

I just had to look at the function names to know that it is about:

tick_do_timer_cpu :)

> [ For those curious, this is the same report on syzbot's moderation
> queue, with line numbers:
> ]

Confirmed :)

So you have quite some of the same report collected and there are a few
other patterns which are all related to tick_do_timer_cpu, so I assume
there is a stash of the other variants as well. And indeed:

It might be useful to find the actual variable, data member or whatever
which is involved in the various reports and if there is a match then
the reports could be aggregated. The 3 patterns here are not even the
complete possible picture.

So if you sum them up: 58 + 148 + 205 instances then their weight
becomes more significant as well.

/me goes back to read the tick_do_timer_cpu comments once more before



  reply	other threads:[~2020-12-05 18:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04 19:03 Naresh Kamboju
2020-12-04 19:53 ` Marco Elver
2020-12-05 18:18   ` Thomas Gleixner [this message]
2020-12-05 23:47     ` Thomas Gleixner
2020-12-07 12:23       ` Marco Elver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: BUG: KCSAN: data-race in tick_nohz_next_event / tick_nohz_stop_tick' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).