From: Eric Dumazet <eric.dumazet@gmail.com>
To: Will Deacon <will@kernel.org>, 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>,
paulmck@linux.ibm.com, Paul Turner <pjt@google.com>,
Daniel Axtens <dja@axtens.net>,
Anatol Pomazau <anatol@google.com>,
Andrea Parri <parri.andrea@gmail.com>,
stern@rowland.harvard.edu, akiyks@gmail.com, npiggin@gmail.com,
boqun.feng@gmail.com, dlustig@nvidia.com, j.alglave@ucl.ac.uk,
luc.maranget@inria.fr
Subject: Re: Kernel Concurrency Sanitizer (KCSAN)
Date: Fri, 4 Oct 2019 17:58:33 -0700 [thread overview]
Message-ID: <0715d98b-12e9-fd81-31d1-67bcb752b0a1@gmail.com> (raw)
In-Reply-To: <20190920155420.rxiflqdrpzinncpy@willie-the-truck>
On 9/20/19 8:54 AM, Will Deacon wrote:
>
> This one is tricky. What I think we need to avoid is an onslaught of
> patches adding READ_ONCE/WRITE_ONCE without a concrete analysis of the
> code being modified. My worry is that Joe Developer is eager to get their
> first patch into the kernel, so runs this tool and starts spamming
> maintainers with these things to the point that they start ignoring KCSAN
> reports altogether because of the time they take up.
>
> I suppose one thing we could do is to require each new READ_ONCE/WRITE_ONCE
> to have a comment describing the racy access, a bit like we do for memory
> barriers. Another possibility would be to use atomic_t more widely if
> there is genuine concurrency involved.
>
About READ_ONCE() and WRITE_ONCE(), we will probably need
ADD_ONCE(var, value) for arches that can implement the RMW in a single instruction.
WRITE_ONCE(var, var + value) does not look pretty, and increases register pressure.
I had a look at first KCSAN reports, and I can tell that tcp_poll() being lockless
means we need to add hundreds of READ_ONCE(), WRITE_ONCE() and ADD_ONCE() all over the places.
-> Absolute nightmare for future backports to stable branches.
next prev parent reply other threads:[~2019-10-05 0:58 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-20 14:18 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 [this message]
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
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=0715d98b-12e9-fd81-31d1-67bcb752b0a1@gmail.com \
--to=eric.dumazet@gmail.com \
--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=will@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
all inboxes | Powered by JetHome®