All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: elver@google.com, "Paul E . McKenney" <paulmck@kernel.org>
Cc: Alexander Potapenko <glider@google.com>,
	Boqun Feng <boqun.feng@gmail.com>, Borislav Petkov <bp@alien8.de>,
	Dmitry Vyukov <dvyukov@google.com>,
	Ingo Molnar <mingo@kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Waiman Long <longman@redhat.com>, Will Deacon <will@kernel.org>,
	kasan-dev@googlegroups.com, linux-arch@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org
Subject: [PATCH -rcu/kcsan 00/23] kcsan: Support detecting a subset of missing memory barriers
Date: Tue,  5 Oct 2021 12:58:42 +0200	[thread overview]
Message-ID: <20211005105905.1994700-1-elver@google.com> (raw)

Detection of some missing memory barriers has been on the KCSAN feature
wishlist for some time: this series adds support for modeling a subset
of weak memory as defined by the LKMM, which enables detection of a
subset of data races due to missing memory barriers.

KCSAN's approach to detecting missing memory barriers is based on
modeling access reordering. Each memory access for which a watchpoint is
set up, is also selected for simulated reordering within the scope of
its function (at most 1 in-flight access).

We are limited to modeling the effects of "buffering" (delaying the
access), since the runtime cannot "prefetch" accesses. Once an access
has been selected for reordering, it is checked along every other access
until the end of the function scope. If an appropriate memory barrier is
encountered, the access will no longer be considered for reordering.

When the result of a memory operation should be ordered by a barrier,
KCSAN can then detect data races where the conflict only occurs as a
result of a missing barrier due to reordering accesses.

Some more details and an example are captured in the updated
<Documentation/dev-tools/kcsan.rst>.

Some light fuzzing with the feature also resulted in a discussion [1]
around an issue which appears to be allowed, but unlikely in practice.

[1] https://lkml.kernel.org/r/YRo58c+JGOvec7tc@elver.google.com


The first half of the series are core KCSAN changes, documentation
updates, and test changes. The second half adds instrumentation to
barriers, atomics, bitops, along with enabling barrier instrumentation
for some currently uninstrumented subsystems. The last two patches are
objtool changes to add the usual entries to the uaccess whitelist, but
also instruct objtool to remove memory barrier instrumentation from
noinstr code (on x86).

The series is rebased on -rcu/kcsan. The objtool patches currently
conflict with pending changes in -tip/objtool/core, which could be
separated from this series if needed.

Marco Elver (23):
  kcsan: Refactor reading of instrumented memory
  kcsan: Remove redundant zero-initialization of globals
  kcsan: Avoid checking scoped accesses from nested contexts
  kcsan: Add core support for a subset of weak memory modeling
  kcsan: Add core memory barrier instrumentation functions
  kcsan, kbuild: Add option for barrier instrumentation only
  kcsan: Call scoped accesses reordered in reports
  kcsan: Show location access was reordered to
  kcsan: Document modeling of weak memory
  kcsan: test: Match reordered or normal accesses
  kcsan: test: Add test cases for memory barrier instrumentation
  kcsan: Ignore GCC 11+ warnings about TSan runtime support
  kcsan: selftest: Add test case to check memory barrier instrumentation
  locking/barriers, kcsan: Add instrumentation for barriers
  locking/barriers, kcsan: Support generic instrumentation
  locking/atomics, kcsan: Add instrumentation for barriers
  asm-generic/bitops, kcsan: Add instrumentation for barriers
  x86/barriers, kcsan: Use generic instrumentation for non-smp barriers
  x86/qspinlock, kcsan: Instrument barrier of pv_queued_spin_unlock()
  mm, kcsan: Enable barrier instrumentation
  sched, kcsan: Enable memory barrier instrumentation
  objtool, kcsan: Add memory barrier instrumentation to whitelist
  objtool, kcsan: Remove memory barrier instrumentation from noinstr

 Documentation/dev-tools/kcsan.rst             |  72 ++-
 arch/x86/include/asm/barrier.h                |  10 +-
 arch/x86/include/asm/qspinlock.h              |   1 +
 include/asm-generic/barrier.h                 |  54 ++-
 .../asm-generic/bitops/instrumented-atomic.h  |   3 +
 .../asm-generic/bitops/instrumented-lock.h    |   3 +
 include/linux/atomic/atomic-instrumented.h    | 135 +++++-
 include/linux/kcsan-checks.h                  |  51 ++-
 include/linux/kcsan.h                         |  11 +-
 include/linux/sched.h                         |   3 +
 include/linux/spinlock.h                      |   2 +-
 init/init_task.c                              |   9 +-
 kernel/kcsan/Makefile                         |   2 +
 kernel/kcsan/core.c                           | 326 +++++++++++---
 kernel/kcsan/kcsan_test.c                     | 416 ++++++++++++++++--
 kernel/kcsan/report.c                         |  51 ++-
 kernel/kcsan/selftest.c                       | 141 ++++++
 kernel/sched/Makefile                         |   7 +-
 lib/Kconfig.kcsan                             |  16 +
 mm/Makefile                                   |   2 +
 scripts/Makefile.kcsan                        |  15 +-
 scripts/Makefile.lib                          |   5 +
 scripts/atomic/gen-atomic-instrumented.sh     |  41 +-
 tools/objtool/check.c                         |  36 +-
 24 files changed, 1240 insertions(+), 172 deletions(-)

-- 
2.33.0.800.g4c38ced690-goog


             reply	other threads:[~2021-10-05 10:59 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 10:58 Marco Elver [this message]
2021-10-05 10:58 ` [PATCH -rcu/kcsan 01/23] kcsan: Refactor reading of instrumented memory Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 02/23] kcsan: Remove redundant zero-initialization of globals Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 03/23] kcsan: Avoid checking scoped accesses from nested contexts Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 04/23] kcsan: Add core support for a subset of weak memory modeling Marco Elver
2021-10-05 12:52   ` Peter Zijlstra
2021-10-05 13:13     ` Marco Elver
2021-10-05 14:20       ` Peter Zijlstra
2021-10-05 10:58 ` [PATCH -rcu/kcsan 05/23] kcsan: Add core memory barrier instrumentation functions Marco Elver
2021-10-05 11:41   ` Peter Zijlstra
2021-10-05 11:45     ` Peter Zijlstra
2021-10-05 11:50       ` Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 06/23] kcsan, kbuild: Add option for barrier instrumentation only Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 07/23] kcsan: Call scoped accesses reordered in reports Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 08/23] kcsan: Show location access was reordered to Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 09/23] kcsan: Document modeling of weak memory Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 10/23] kcsan: test: Match reordered or normal accesses Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 11/23] kcsan: test: Add test cases for memory barrier instrumentation Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 12/23] kcsan: Ignore GCC 11+ warnings about TSan runtime support Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 13/23] kcsan: selftest: Add test case to check memory barrier instrumentation Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 14/23] locking/barriers, kcsan: Add instrumentation for barriers Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 15/23] locking/barriers, kcsan: Support generic instrumentation Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 16/23] locking/atomics, kcsan: Add instrumentation for barriers Marco Elver
2021-10-05 12:02   ` Peter Zijlstra
2021-10-05 12:16     ` Marco Elver
2021-10-05 10:58 ` [PATCH -rcu/kcsan 17/23] asm-generic/bitops, " Marco Elver
2021-10-05 10:59 ` [PATCH -rcu/kcsan 18/23] x86/barriers, kcsan: Use generic instrumentation for non-smp barriers Marco Elver
2021-10-05 10:59 ` [PATCH -rcu/kcsan 19/23] x86/qspinlock, kcsan: Instrument barrier of pv_queued_spin_unlock() Marco Elver
2021-10-05 10:59 ` [PATCH -rcu/kcsan 20/23] mm, kcsan: Enable barrier instrumentation Marco Elver
2021-10-05 10:59 ` [PATCH -rcu/kcsan 21/23] sched, kcsan: Enable memory " Marco Elver
2021-10-05 10:59 ` [PATCH -rcu/kcsan 22/23] objtool, kcsan: Add memory barrier instrumentation to whitelist Marco Elver
2021-10-05 10:59 ` [PATCH -rcu/kcsan 23/23] objtool, kcsan: Remove memory barrier instrumentation from noinstr Marco Elver
2021-10-05 14:37   ` Peter Zijlstra
2021-10-05 15:13     ` Marco Elver
2021-11-11 10:11       ` Marco Elver
2021-11-11 11:35         ` Peter Zijlstra

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=20211005105905.1994700-1-elver@google.com \
    --to=elver@google.com \
    --cc=boqun.feng@gmail.com \
    --cc=bp@alien8.de \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=longman@redhat.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@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 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.