From: Joel Fernandes <joel@joelfernandes.org>
To: Marco Elver <elver@google.com>
Cc: kasan-dev <kasan-dev@googlegroups.com>,
LKML <linux-kernel@vger.kernel.org>,
Dmitry Vyukov <dvyukov@google.com>,
Andrey Konovalov <andreyknvl@google.com>,
Alexander Potapenko <glider@google.com>,
"Paul E. McKenney" <paulmck@linux.ibm.com>,
Paul Turner <pjt@google.com>, Daniel Axtens <dja@axtens.net>,
Anatol Pomazau <anatol@google.com>,
Will Deacon <willdeacon@google.com>,
Andrea Parri <parri.andrea@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>,
Nicholas Piggin <npiggin@gmail.com>,
Boqun Feng <boqun.feng@gmail.com>,
Daniel Lustig <dlustig@nvidia.com>,
Jade Alglave <j.alglave@ucl.ac.uk>,
Luc Maranget <luc.maranget@inria.fr>
Subject: Re: Kernel Concurrency Sanitizer (KCSAN)
Date: Fri, 4 Oct 2019 12:48:59 -0400 [thread overview]
Message-ID: <20191004164859.GD253167@google.com> (raw)
In-Reply-To: <CANpmjNNp=zVzM2iGcQwVYxzNHYjBo==_2nito4Dw=kHopy=0Sg@mail.gmail.com>
On Wed, Oct 02, 2019 at 09:51:58PM +0200, Marco Elver wrote:
> Hi Joel,
>
> On Tue, 1 Oct 2019 at 23:19, Joel Fernandes <joel@joelfernandes.org> wrote:
> >
> > On Fri, Sep 20, 2019 at 04:18:57PM +0200, Marco Elver wrote:
> > > Hi all,
> > >
> > > We would like to share a new data-race detector for the Linux kernel:
> > > Kernel Concurrency Sanitizer (KCSAN) --
> > > https://github.com/google/ktsan/wiki/KCSAN (Details:
> > > https://github.com/google/ktsan/blob/kcsan/Documentation/dev-tools/kcsan.rst)
> > >
> > > To those of you who we mentioned at LPC that we're working on a
> > > watchpoint-based KTSAN inspired by DataCollider [1], this is it (we
> > > renamed it to KCSAN to avoid confusion with KTSAN).
> > > [1] http://usenix.org/legacy/events/osdi10/tech/full_papers/Erickson.pdf
> > >
> > > In the coming weeks we're planning to:
> > > * Set up a syzkaller instance.
> > > * Share the dashboard so that you can see the races that are found.
> > > * Attempt to send fixes for some races upstream (if you find that the
> > > kcsan-with-fixes branch contains an important fix, please feel free to
> > > point it out and we'll prioritize that).
> > >
> > > There are a few open questions:
> > > * The big one: most of the reported races are due to unmarked
> > > accesses; prioritization or pruning of races to focus initial efforts
> > > to fix races might be required. Comments on how best to proceed are
> > > welcome. We're aware that these are issues that have recently received
> > > attention in the context of the LKMM
> > > (https://lwn.net/Articles/793253/).
> > > * How/when to upstream KCSAN?
> >
> > Looks exciting. I think based on our discussion at LPC, you mentioned
> > one way of pruning is if the compiler generated different code with _ONCE
> > annotations than what would have otherwise been generated. Is that still on
> > the table, for the purposing of pruning the reports?
>
> This might be interesting at first, but it's not entirely clear how
> feasible it is. It's also dangerous, because the real issue would be
> ignored. It may be that one compiler version on a particular
> architecture generates the same code, but any change in compiler or
> architecture and this would no longer be true. Let me know if you have
> any more ideas.
My thought was this technique of looking at compiler generated code can be
used for prioritization of the reports. Have you tested it though? I think
without testing such technique, we could not know how much of benefit (or
lack thereof) there is to the issue.
In fact, IIRC, the compiler generating different code with _ONCE annotation
can be given as justification for patches doing such conversions.
thanks,
- Joel
next prev parent reply other threads:[~2019-10-04 16:49 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-20 14:18 Kernel Concurrency Sanitizer (KCSAN) Marco Elver
2019-09-20 15:54 ` Will Deacon
2019-09-20 17:50 ` Marco Elver
2019-09-23 4:31 ` Boqun Feng
2019-09-23 8:21 ` Dmitry Vyukov
2019-09-23 8:54 ` Boqun Feng
2019-09-23 8:59 ` Dmitry Vyukov
2019-09-23 11:01 ` Marco Elver
2019-09-23 12:32 ` Boqun Feng
2019-10-05 0:58 ` Eric Dumazet
2019-10-05 4:16 ` Dmitry Vyukov
2019-10-09 7:45 ` Dmitry Vyukov
2019-10-09 16:39 ` Eric Dumazet
2019-10-09 20:17 ` Andrea Parri
2019-09-20 16:31 ` Mark Rutland
2019-09-20 16:46 ` Dmitry Vyukov
2019-09-20 17:51 ` Marco Elver
2019-10-03 16:12 ` Mark Rutland
2019-10-03 19:27 ` Marco Elver
2019-10-01 14:50 ` Daniel Axtens
2019-10-02 19:42 ` Marco Elver
2019-10-11 3:45 ` Daniel Axtens
2019-10-01 21:19 ` Joel Fernandes
2019-10-02 19:51 ` Marco Elver
2019-10-03 13:13 ` Dmitry Vyukov
2019-10-03 16:00 ` Dmitry Vyukov
2019-10-03 19:39 ` Christian Brauner
2019-10-04 16:48 ` Joel Fernandes [this message]
2019-10-04 16:52 ` Dmitry Vyukov
2019-10-04 16:57 ` Joel Fernandes
2019-10-04 17:01 ` Dmitry Vyukov
2019-10-04 18:08 ` Joel Fernandes
2019-10-04 18:28 ` Dmitry Vyukov
[not found] ` <CADyx2V6j+do+CmmSYEUr0iP7TUWD7xHLP2ZJPrqB1Y+QEAwzhw@mail.gmail.com>
2019-12-12 20:53 ` 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:
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=20191004164859.GD253167@google.com \
--to=joel@joelfernandes.org \
--cc=akiyks@gmail.com \
--cc=anatol@google.com \
--cc=andreyknvl@google.com \
--cc=boqun.feng@gmail.com \
--cc=dja@axtens.net \
--cc=dlustig@nvidia.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=j.alglave@ucl.ac.uk \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@linux.ibm.com \
--cc=pjt@google.com \
--cc=stern@rowland.harvard.edu \
--cc=willdeacon@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.