From: "Paul E. McKenney" <paulmck@kernel.org>
To: Marco Elver <elver@google.com>
Cc: Will Deacon <will@kernel.org>,
kasan-dev <kasan-dev@googlegroups.com>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>,
Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH v5 00/18] Rework READ_ONCE() to improve codegen
Date: Thu, 14 May 2020 08:38:05 -0700 [thread overview]
Message-ID: <20200514153805.GK2869@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <CANpmjNMTsY_8241bS7=XAfqvZHFLrVEkv_uM4aDUWE_kh3Rvbw@mail.gmail.com>
On Thu, May 14, 2020 at 03:35:58PM +0200, Marco Elver wrote:
> On Thu, 14 May 2020 at 13:05, Will Deacon <will@kernel.org> wrote:
> >
> > Hi Marco,
> >
> > On Thu, May 14, 2020 at 09:31:49AM +0200, Marco Elver wrote:
> > > Ouch. With the __{READ,WRITE}_ONCE requirement, we're going to need
> > > Clang 11 though.
> > >
> > > Because without the data_race() around __*_ONCE,
> > > arch_atomic_{read,set} will be broken for KCSAN, but we can't have
> > > data_race() because it would still add
> > > kcsan_{enable,disable}_current() calls to __no_sanitize functions (if
> > > compilation unit is instrumented). We can't make arch_atomic functions
> > > __no_sanitize_or_inline, because even in code that we want to
> > > sanitize, they should remain __always_inline (so they work properly in
> > > __no_sanitize functions). Therefore, Clang 11 with support for
> > > distinguishing volatiles will be the compiler that will satisfy all
> > > the constraints.
> > >
> > > If this is what we want, let me prepare a series on top of
> > > -tip/locking/kcsan with all the things I think we need.
> >
> > Stepping back a second, the locking/kcsan branch is at least functional at
> > the moment by virtue of KCSAN_SANITIZE := n being used liberally in
> > arch/x86/. However, I still think we want to do better than that because (a)
> > it would be good to get more x86 coverage and (b) enabling this for arm64,
> > where objtool is not yet available, will be fragile if we have to whitelist
> > object files. There's also a fair bit of arm64 low-level code spread around
> > drivers/, so it feels like we'd end up with a really bad case of whack-a-mole.
> >
> > Talking off-list, Clang >= 7 is pretty reasonable wrt inlining decisions
> > and the behaviour for __always_inline is:
> >
> > * An __always_inline function inlined into a __no_sanitize function is
> > not instrumented
> > * An __always_inline function inlined into an instrumented function is
> > instrumented
> > * You can't mark a function as both __always_inline __no_sanitize, because
> > __no_sanitize functions are never inlined
> >
> > GCC, on the other hand, may still inline __no_sanitize functions and then
> > subsequently instrument them.
> >
> > So if were willing to make KCSAN depend on Clang >= 7, then we could:
> >
> > - Remove the data_race() from __{READ,WRITE}_ONCE()
> > - Wrap arch_atomic*() in data_race() when called from the instrumented
> > atomic wrappers
> >
> > At which point, I *think* everything works as expected. READ_ONCE_NOCHECK()
> > won't generate any surprises, and Peter can happily use arch_atomic()
> > from non-instrumented code.
> >
> > Thoughts? I don't see the need to support buggy compilers when enabling
> > a new debug feature.
>
> This is also a reply to
> https://lkml.kernel.org/r/20200514122038.GH3001@hirez.programming.kicks-ass.net
> -- the problem with __READ_ONCE would be solved with what Will
> proposed above.
>
> Let me try to spell out the requirements I see so far (this is for
> KCSAN only though -- other sanitizers might be similar):
>
> 1. __no_kcsan functions should not call anything, not even
> kcsan_{enable,disable}_current(), when using __{READ,WRITE}_ONCE.
> [Requires leaving data_race() off of these.]
>
> 2. __always_inline functions inlined into __no_sanitize function is
> not instrumented. [Has always been satisfied by GCC and Clang.]
>
> 3. __always_inline functions inlined into instrumented function is
> instrumented. [Has always been satisfied by GCC and Clang.]
>
> 4. __no_kcsan functions should never be spuriously inlined into
> instrumented functions, causing the accesses of the __no_kcsan
> function to be instrumented. [Satisfied by Clang >= 7. All GCC
> versions are broken.]
>
> 5. we should not break atomic_{read,set} for KCSAN. [Because of #1,
> we'd need to add data_race() around the arch-calls in
> atomic_{read,set}; or rely on Clang 11's -tsan-distinguish-volatile
> support (GCC 11 might get this as well).]
>
> 6. never emit __tsan_func_{entry,exit}. [Clang supports disabling
> this, GCC doesn't.]
>
> 7. kernel is supported by compiler. [Clang >= 9 seems to build -tip
> for me, anything below complains about lack of asm goto. GCC trivial.]
>
> So, because of #4 & #6 & #7 we're down to Clang >= 9. Because of #5
> we'll have to make a choice between Clang >= 9 or Clang >= 11
> (released in ~June). In an ideal world we might even fix GCC in
> future.
>
> That's not even considering the problems around UBSan and KASAN. But
> maybe one step at a time?
>
> Any preferences?
I am already having to choose where I run KCSAN based on what compiler
is available, so I cannot argue too hard against a dependency on a
specific compiler. I reserve the right to ask for help installing it,
if need be though. ;-)
Thanx, Paul
next prev parent reply other threads:[~2020-05-14 15:38 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 20:41 [PATCH v5 00/18] Rework READ_ONCE() to improve codegen Will Deacon
2020-05-11 20:41 ` [PATCH v5 01/18] sparc32: mm: Fix argument checking in __srmmu_get_nocache() Will Deacon
2020-05-12 14:37 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 02/18] sparc32: mm: Restructure sparc32 MMU page-table layout Will Deacon
2020-05-12 14:37 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 03/18] sparc32: mm: Change pgtable_t type to pte_t * instead of struct page * Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 04/18] sparc32: mm: Reduce allocation size for PMD and PTE tables Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-17 0:00 ` [PATCH v5 04/18] " Guenter Roeck
2020-05-17 0:07 ` Guenter Roeck
2020-05-18 8:37 ` Will Deacon
2020-05-18 9:18 ` Mike Rapoport
2020-05-18 9:48 ` Guenter Roeck
2020-05-18 14:23 ` Mike Rapoport
2020-05-18 16:08 ` Guenter Roeck
2020-05-18 18:11 ` Ira Weiny
2020-05-18 18:14 ` Ira Weiny
2020-05-18 18:09 ` Guenter Roeck
2020-05-18 18:21 ` Ira Weiny
2020-05-18 19:15 ` Mike Rapoport
2020-05-19 16:40 ` Guenter Roeck
2020-05-20 17:03 ` Mike Rapoport
2020-05-20 19:03 ` Guenter Roeck
2020-05-20 19:51 ` Mike Rapoport
2020-05-21 23:02 ` Guenter Roeck
2020-05-24 12:32 ` Mike Rapoport
2020-05-24 14:01 ` Guenter Roeck
2020-05-26 13:26 ` Will Deacon
2020-05-26 14:01 ` Will Deacon
2020-05-26 15:21 ` Mike Rapoport
2020-05-26 16:18 ` Guenter Roeck
2020-05-26 16:29 ` Mike Rapoport
2020-05-26 17:15 ` Guenter Roeck
2020-05-11 20:41 ` [PATCH v5 05/18] compiler/gcc: Raise minimum GCC version for kernel builds to 4.8 Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 06/18] netfilter: Avoid assigning 'const' pointer to non-const pointer Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 07/18] net: tls: " Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 08/18] fault_inject: Don't rely on "return value" from WRITE_ONCE() Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 09/18] arm64: csum: Disable KASAN for do_csum() Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 10/18] READ_ONCE: Simplify implementations of {READ,WRITE}_ONCE() Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 11/18] READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 12/18] READ_ONCE: Drop pointer qualifiers when reading from scalar types Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 13/18] locking/barriers: Use '__unqual_scalar_typeof' for load-acquire macros Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 14/18] arm64: barrier: Use '__unqual_scalar_typeof' for acquire/release macros Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 15/18] gcov: Remove old GCC 3.4 support Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 16/18] kcsan: Rework data_race() so that it can be used by READ_ONCE() Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-11 20:41 ` [PATCH v5 17/18] READ_ONCE: Use data_race() to avoid KCSAN instrumentation Will Deacon
2020-05-12 8:23 ` Peter Zijlstra
2020-05-12 9:49 ` Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-20 22:17 ` Borislav Petkov
2020-05-20 22:30 ` Marco Elver
2020-05-21 7:25 ` Borislav Petkov
2020-05-21 9:37 ` Marco Elver
2020-05-21 3:30 ` Nathan Chancellor
2020-05-22 16:08 ` [tip: locking/kcsan] compiler.h: Avoid nested statement expression in data_race() tip-bot2 for Marco Elver
2020-05-11 20:41 ` [PATCH v5 18/18] linux/compiler.h: Remove redundant '#else' Will Deacon
2020-05-12 14:36 ` [tip: locking/kcsan] " tip-bot2 for Will Deacon
2020-05-12 8:18 ` [PATCH v5 00/18] Rework READ_ONCE() to improve codegen Peter Zijlstra
2020-05-12 17:53 ` Marco Elver
2020-05-12 18:55 ` Marco Elver
2020-05-12 19:07 ` Peter Zijlstra
2020-05-12 20:31 ` Marco Elver
2020-05-13 11:10 ` Peter Zijlstra
2020-05-13 11:14 ` Peter Zijlstra
2020-05-13 11:48 ` Marco Elver
2020-05-13 12:32 ` Peter Zijlstra
2020-05-13 12:40 ` Will Deacon
2020-05-13 13:15 ` Marco Elver
2020-05-13 13:24 ` Peter Zijlstra
2020-05-13 13:58 ` Marco Elver
2020-05-14 11:21 ` Peter Zijlstra
2020-05-14 11:24 ` Peter Zijlstra
2020-05-14 11:35 ` Peter Zijlstra
2020-05-14 12:01 ` Will Deacon
2020-05-14 12:27 ` Peter Zijlstra
2020-05-14 13:07 ` Marco Elver
2020-05-14 13:14 ` Peter Zijlstra
2020-05-14 12:20 ` Peter Zijlstra
2020-05-14 14:13 ` Peter Zijlstra
2020-05-14 14:20 ` Marco Elver
2020-05-15 9:20 ` Peter Zijlstra
2020-05-13 16:50 ` Will Deacon
2020-05-13 17:32 ` Marco Elver
2020-05-13 17:47 ` Will Deacon
2020-05-13 18:54 ` Marco Elver
2020-05-13 21:25 ` Will Deacon
2020-05-14 7:31 ` Marco Elver
2020-05-14 11:05 ` Will Deacon
2020-05-14 13:35 ` Marco Elver
2020-05-14 13:47 ` Peter Zijlstra
2020-05-14 13:50 ` Peter Zijlstra
2020-05-14 13:56 ` Peter Zijlstra
2020-05-14 14:24 ` Peter Zijlstra
2020-05-14 15:09 ` Thomas Gleixner
2020-05-14 15:29 ` Marco Elver
2020-05-14 19:37 ` Thomas Gleixner
2020-05-15 13:55 ` David Laight
2020-05-15 14:04 ` Marco Elver
2020-05-15 14:07 ` Peter Zijlstra
2020-05-14 15:38 ` Paul E. McKenney [this message]
2020-05-22 16:08 ` [tip: locking/kcsan] kcsan: Restrict supported compilers tip-bot2 for Marco Elver
2020-06-03 18:52 ` [PATCH v5 00/18] Rework READ_ONCE() to improve codegen Borislav Petkov
2020-06-03 19:23 ` Marco Elver
2020-06-03 22:05 ` Borislav Petkov
2020-06-08 17:32 ` Martin Liška
2020-06-08 19:56 ` Marco Elver
2020-06-09 11:55 ` Martin Liška
2020-06-09 12:36 ` Martin Liška
2020-06-09 13:45 ` Marco Elver
2020-05-22 16:08 ` [tip: locking/kcsan] kcsan: Remove 'noinline' from __no_kcsan_or_inline tip-bot2 for Marco Elver
2020-05-13 13:21 ` [PATCH v5 00/18] Rework READ_ONCE() to improve codegen David Laight
2020-05-13 16:32 ` Thomas Gleixner
2020-05-12 21:14 ` Will Deacon
2020-05-12 22:00 ` 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=20200514153805.GK2869@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--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;
as well as URLs for NNTP newsgroup(s).