From: Will Deacon <will@kernel.org>
To: Marco Elver <elver@google.com>
Cc: paulmck@kernel.org, dvyukov@google.com, glider@google.com,
andreyknvl@google.com, kasan-dev@googlegroups.com,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@kernel.org, peterz@infradead.org,
clang-built-linux@googlegroups.com, bp@alien8.de
Subject: Re: [PATCH -tip v2 03/11] kcsan: Support distinguishing volatile accesses
Date: Thu, 21 May 2020 14:18:04 +0100 [thread overview]
Message-ID: <20200521131803.GA6608@willie-the-truck> (raw)
In-Reply-To: <20200521110854.114437-4-elver@google.com>
On Thu, May 21, 2020 at 01:08:46PM +0200, Marco Elver wrote:
> In the kernel, volatile is used in various concurrent context, whether
> in low-level synchronization primitives or for legacy reasons. If
> supported by the compiler, we will assume that aligned volatile accesses
> up to sizeof(long long) (matching compiletime_assert_rwonce_type()) are
> atomic.
>
> Recent versions Clang [1] (GCC tentative [2]) can instrument volatile
> accesses differently. Add the option (required) to enable the
> instrumentation, and provide the necessary runtime functions. None of
> the updated compilers are widely available yet (Clang 11 will be the
> first release to support the feature).
>
> [1] https://github.com/llvm/llvm-project/commit/5a2c31116f412c3b6888be361137efd705e05814
> [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544452.html
>
> This patch allows removing any explicit checks in primitives such as
> READ_ONCE() and WRITE_ONCE().
>
> Signed-off-by: Marco Elver <elver@google.com>
> ---
> v2:
> * Reword Makefile comment.
> ---
> kernel/kcsan/core.c | 43 ++++++++++++++++++++++++++++++++++++++++++
> scripts/Makefile.kcsan | 5 ++++-
> 2 files changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
> index a73a66cf79df..15f67949d11e 100644
> --- a/kernel/kcsan/core.c
> +++ b/kernel/kcsan/core.c
> @@ -789,6 +789,49 @@ void __tsan_write_range(void *ptr, size_t size)
> }
> EXPORT_SYMBOL(__tsan_write_range);
>
> +/*
> + * Use of explicit volatile is generally disallowed [1], however, volatile is
> + * still used in various concurrent context, whether in low-level
> + * synchronization primitives or for legacy reasons.
> + * [1] https://lwn.net/Articles/233479/
> + *
> + * We only consider volatile accesses atomic if they are aligned and would pass
> + * the size-check of compiletime_assert_rwonce_type().
> + */
> +#define DEFINE_TSAN_VOLATILE_READ_WRITE(size) \
> + void __tsan_volatile_read##size(void *ptr) \
> + { \
> + const bool is_atomic = size <= sizeof(long long) && \
> + IS_ALIGNED((unsigned long)ptr, size); \
> + if (IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS) && is_atomic) \
> + return; \
> + check_access(ptr, size, is_atomic ? KCSAN_ACCESS_ATOMIC : 0); \
> + } \
> + EXPORT_SYMBOL(__tsan_volatile_read##size); \
> + void __tsan_unaligned_volatile_read##size(void *ptr) \
> + __alias(__tsan_volatile_read##size); \
> + EXPORT_SYMBOL(__tsan_unaligned_volatile_read##size); \
> + void __tsan_volatile_write##size(void *ptr) \
> + { \
> + const bool is_atomic = size <= sizeof(long long) && \
> + IS_ALIGNED((unsigned long)ptr, size); \
> + if (IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS) && is_atomic) \
> + return; \
> + check_access(ptr, size, \
> + KCSAN_ACCESS_WRITE | \
> + (is_atomic ? KCSAN_ACCESS_ATOMIC : 0)); \
> + } \
> + EXPORT_SYMBOL(__tsan_volatile_write##size); \
> + void __tsan_unaligned_volatile_write##size(void *ptr) \
> + __alias(__tsan_volatile_write##size); \
> + EXPORT_SYMBOL(__tsan_unaligned_volatile_write##size)
> +
> +DEFINE_TSAN_VOLATILE_READ_WRITE(1);
> +DEFINE_TSAN_VOLATILE_READ_WRITE(2);
> +DEFINE_TSAN_VOLATILE_READ_WRITE(4);
> +DEFINE_TSAN_VOLATILE_READ_WRITE(8);
> +DEFINE_TSAN_VOLATILE_READ_WRITE(16);
Having a 16-byte case seems a bit weird to me, but I guess clang needs this
for some reason?
Will
next prev parent reply other threads:[~2020-05-21 13:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-21 11:08 [PATCH -tip v2 00/11] Fix KCSAN for new ONCE (require Clang 11) Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 01/11] ubsan, kcsan: don't combine sanitizer with kcov on clang Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 02/11] kcsan: Avoid inserting __tsan_func_entry/exit if possible Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 03/11] kcsan: Support distinguishing volatile accesses Marco Elver
2020-05-21 13:18 ` Will Deacon [this message]
2020-05-21 13:26 ` Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 04/11] kcsan: Pass option tsan-instrument-read-before-write to Clang Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 05/11] kcsan: Remove 'noinline' from __no_kcsan_or_inline Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 06/11] kcsan: Restrict supported compilers Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 07/11] kcsan: Update Documentation to change " Marco Elver
2020-05-21 13:33 ` Will Deacon
2020-05-21 13:35 ` Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 08/11] READ_ONCE, WRITE_ONCE: Remove data_race() and unnecessary checks Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 09/11] data_race: Avoid nested statement expression Marco Elver
2020-05-21 13:31 ` Will Deacon
2020-05-21 13:39 ` Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 10/11] compiler.h: Move function attributes to compiler_types.h Marco Elver
2020-05-21 11:08 ` [PATCH -tip v2 11/11] compiler_types.h, kasan: Use __SANITIZE_ADDRESS__ instead of CONFIG_KASAN to decide inlining Marco Elver
2020-05-21 13:36 ` [PATCH -tip v2 00/11] Fix KCSAN for new ONCE (require Clang 11) Will Deacon
2020-05-21 13:42 ` Marco Elver
2020-05-21 13:42 ` Will Deacon
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=20200521131803.GA6608@willie-the-truck \
--to=will@kernel.org \
--cc=andreyknvl@google.com \
--cc=bp@alien8.de \
--cc=clang-built-linux@googlegroups.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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®