From: "Paul E. McKenney" <paulmck@kernel.org>
To: Marco Elver <elver@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
kasan-dev <kasan-dev@googlegroups.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -rcu 0/2] kcsan: Improvements to reporting
Date: Thu, 9 Jan 2020 12:46:41 -0800 [thread overview]
Message-ID: <20200109204641.GW13449@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <CANpmjNP=8cfqgXkz7f8D6STTn1-2h9qzUery4qMHeTTeNJOdxQ@mail.gmail.com>
On Thu, Jan 09, 2020 at 06:42:16PM +0100, Marco Elver wrote:
> On Thu, 9 Jan 2020 at 18:31, Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > On Thu, Jan 09, 2020 at 06:03:39PM +0100, Marco Elver wrote:
> > > On Thu, 9 Jan 2020 at 17:27, Paul E. McKenney <paulmck@kernel.org> wrote:
> > > >
> > > > On Thu, Jan 09, 2020 at 04:23:20PM +0100, Marco Elver wrote:
> > > > > Improvements to KCSAN data race reporting:
> > > > > 1. Show if access is marked (*_ONCE, atomic, etc.).
> > > > > 2. Rate limit reporting to avoid spamming console.
> > > > >
> > > > > Marco Elver (2):
> > > > > kcsan: Show full access type in report
> > > > > kcsan: Rate-limit reporting per data races
> > > >
> > > > Queued and pushed, thank you! I edited the commit logs a bit, so could
> > > > you please check to make sure that I didn't mess anything up?
> > >
> > > Looks good to me, thank you.
> > >
> > > > At some point, boot-time-allocated per-CPU arrays might be needed to
> > > > avoid contention on large systems, but one step at a time. ;-)
> > >
> > > I certainly hope the rate of fixing/avoiding data races will not be
> > > eclipsed by the rate at which new ones are introduced. :-)
> >
> > Me too!
> >
> > However, on a large system, duplicate reports might happen quite
> > frequently, which might cause slowdowns given the single global
> > array. Or maybe not -- I guess we will find out soon enough. ;-)
> >
> > But I must confess that I am missing how concurrent access to the
> > report_times[] array is handled. I would have expected that
> > rate_limit_report() would choose a random starting entry and
> > search circularly. And I would expect that the code at the end
> > of that function would instead look something like this:
> >
> > if (ktime_before(oldtime, invalid_before) &&
> > cmpxchg(&use_entry->time, oldtime, now) == oldtime) {
> > use_entry->frame1 = frame1;
> > use_entry->frame2 = frame2;
> > } else {
> > // Too bad, next duplicate report won't be suppressed.
> > }
> >
> > Where "oldtime" is captured from the entry during the scan, and from the
> > first entry scanned. This cmpxchg() approach is of course vulnerable
> > to the ->frame1 and ->frame2 assignments taking more than three seconds
> > (by default), but if that becomes a problem, a WARN_ON() could be added:
> >
> > if (ktime_before(oldtime, invalid_before) &&
> > cmpxchg(&use_entry->time, oldtime, now) == oldtime) {
> > use_entry->frame1 = frame1;
> > use_entry->frame2 = frame2;
> > WARN_ON_ONCE(use_entry->time != now);
> > } else {
> > // Too bad, next duplicate report won't be suppressed.
> > }
> >
> > So what am I missing here?
>
> Ah right, sorry, I should have clarified or commented in the code that
> all of this is happening under 'report_lock' (taken in prepare_report,
> held in print_report->rate_limit_report, released in release_report).
> That also means that any optimization here won't matter until
> report_lock is removed.
Got it, thank you! And yes, lock contention on report_lock might be
a problem on large systems. But let's see how it goes.
Thanx, Paul
> Thanks,
> -- Marco
>
> > Thanx, Paul
> >
> > > Thanks,
> > > -- Marco
> > >
> > > > Thanx, Paul
> > > >
> > > > > kernel/kcsan/core.c | 15 +++--
> > > > > kernel/kcsan/kcsan.h | 2 +-
> > > > > kernel/kcsan/report.c | 153 +++++++++++++++++++++++++++++++++++-------
> > > > > lib/Kconfig.kcsan | 10 +++
> > > > > 4 files changed, 148 insertions(+), 32 deletions(-)
> > > > >
> > > > > --
> > > > > 2.25.0.rc1.283.g88dfdc4193-goog
> > > > >
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> > > > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200109162739.GS13449%40paulmck-ThinkPad-P72.
prev parent reply other threads:[~2020-01-09 20:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-09 15:23 [PATCH -rcu 0/2] kcsan: Improvements to reporting Marco Elver
2020-01-09 15:23 ` [PATCH -rcu 1/2] kcsan: Show full access type in report Marco Elver
2020-01-09 15:23 ` [PATCH -rcu 2/2] kcsan: Rate-limit reporting per data races Marco Elver
2020-01-10 18:20 ` Marco Elver
2020-01-10 18:54 ` Marco Elver
2020-01-11 5:13 ` Paul E. McKenney
2020-01-09 16:27 ` [PATCH -rcu 0/2] kcsan: Improvements to reporting Paul E. McKenney
2020-01-09 17:03 ` Marco Elver
2020-01-09 17:31 ` Paul E. McKenney
2020-01-09 17:42 ` Marco Elver
2020-01-09 20:46 ` Paul E. McKenney [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200109204641.GW13449@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=andreyknvl@google.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).