mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
	kernel-team@fb.com, mingo@kernel.org
Cc: elver@google.com, andreyknvl@google.com, glider@google.com,
	dvyukov@google.com, cai@lca.pw, boqun.feng@gmail.com,
	"Paul E . McKenney" <paulmck@kernel.org>
Subject: [PATCH kcsan 28/29] kcsan: Avoid nested contexts reading inconsistent reorder_access
Date: Tue, 14 Dec 2021 14:04:38 -0800	[thread overview]
Message-ID: <20211214220439.2236564-28-paulmck@kernel.org> (raw)
In-Reply-To: <20211214220356.GA2236323@paulmck-ThinkPad-P17-Gen-1>

From: Marco Elver <elver@google.com>

Nested contexts, such as nested interrupts or scheduler code, share the
same kcsan_ctx. When such a nested context reads an inconsistent
reorder_access due to an interrupt during set_reorder_access(), we can
observe the following warning:

 | ------------[ cut here ]------------
 | Cannot find frame for torture_random kernel/torture.c:456 in stack trace
 | WARNING: CPU: 13 PID: 147 at kernel/kcsan/report.c:343 replace_stack_entry kernel/kcsan/report.c:343
 | ...
 | Call Trace:
 |  <TASK>
 |  sanitize_stack_entries kernel/kcsan/report.c:351 [inline]
 |  print_report kernel/kcsan/report.c:409
 |  kcsan_report_known_origin kernel/kcsan/report.c:693
 |  kcsan_setup_watchpoint kernel/kcsan/core.c:658
 |  rcutorture_one_extend kernel/rcu/rcutorture.c:1475
 |  rcutorture_loop_extend kernel/rcu/rcutorture.c:1558 [inline]
 |  ...
 |  </TASK>
 | ---[ end trace ee5299cb933115f5 ]---
 | ==================================================================
 | BUG: KCSAN: data-race in _raw_spin_lock_irqsave / rcutorture_one_extend
 |
 | write (reordered) to 0xffffffff8c93b300 of 8 bytes by task 154 on cpu 12:
 |  queued_spin_lock                include/asm-generic/qspinlock.h:80 [inline]
 |  do_raw_spin_lock                include/linux/spinlock.h:185 [inline]
 |  __raw_spin_lock_irqsave         include/linux/spinlock_api_smp.h:111 [inline]
 |  _raw_spin_lock_irqsave          kernel/locking/spinlock.c:162
 |  try_to_wake_up                  kernel/sched/core.c:4003
 |  sysvec_apic_timer_interrupt     arch/x86/kernel/apic/apic.c:1097
 |  asm_sysvec_apic_timer_interrupt arch/x86/include/asm/idtentry.h:638
 |  set_reorder_access              kernel/kcsan/core.c:416 [inline]    <-- inconsistent reorder_access
 |  kcsan_setup_watchpoint          kernel/kcsan/core.c:693
 |  rcutorture_one_extend           kernel/rcu/rcutorture.c:1475
 |  rcutorture_loop_extend          kernel/rcu/rcutorture.c:1558 [inline]
 |  rcu_torture_one_read            kernel/rcu/rcutorture.c:1600
 |  rcu_torture_reader              kernel/rcu/rcutorture.c:1692
 |  kthread                         kernel/kthread.c:327
 |  ret_from_fork                   arch/x86/entry/entry_64.S:295
 |
 | read to 0xffffffff8c93b300 of 8 bytes by task 147 on cpu 13:
 |  rcutorture_one_extend           kernel/rcu/rcutorture.c:1475
 |  rcutorture_loop_extend          kernel/rcu/rcutorture.c:1558 [inline]
 |  ...

The warning is telling us that there was a data race which KCSAN wants
to report, but the function where the original access (that is now
reordered) happened cannot be found in the stack trace, which prevents
KCSAN from generating the right stack trace. The stack trace of "write
(reordered)" now only shows where the access was reordered to, but
should instead show the stack trace of the original write, with a final
line saying "reordered to".

At the point where set_reorder_access() is interrupted, it just set
reorder_access->ptr and size, at which point size is non-zero. This is
sufficient (if ctx->disable_scoped is zero) for further accesses from
nested contexts to perform checking of this reorder_access.

That then happened in _raw_spin_lock_irqsave(), which is called by
scheduler code. However, since reorder_access->ip is still stale (ptr
and size belong to a different ip not yet set) this finally leads to
replace_stack_entry() not finding the frame in reorder_access->ip and
generating the above warning.

Fix it by ensuring that a nested context cannot access reorder_access
while we update it in set_reorder_access(): set ctx->disable_scoped for
the duration that reorder_access is updated, which effectively locks
reorder_access and prevents concurrent use by nested contexts. Note,
set_reorder_access() can do the update only if disabled_scoped is zero
on entry, and must therefore set disable_scoped back to non-zero after
the initial check in set_reorder_access().

Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
 kernel/kcsan/core.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
index 9160609139666..fe12dfe254ecf 100644
--- a/kernel/kcsan/core.c
+++ b/kernel/kcsan/core.c
@@ -412,11 +412,20 @@ set_reorder_access(struct kcsan_ctx *ctx, const volatile void *ptr, size_t size,
 	if (!reorder_access || !kcsan_weak_memory)
 		return;
 
+	/*
+	 * To avoid nested interrupts or scheduler (which share kcsan_ctx)
+	 * reading an inconsistent reorder_access, ensure that the below has
+	 * exclusive access to reorder_access by disallowing concurrent use.
+	 */
+	ctx->disable_scoped++;
+	barrier();
 	reorder_access->ptr		= ptr;
 	reorder_access->size		= size;
 	reorder_access->type		= type | KCSAN_ACCESS_SCOPED;
 	reorder_access->ip		= ip;
 	reorder_access->stack_depth	= get_kcsan_stack_depth();
+	barrier();
+	ctx->disable_scoped--;
 }
 
 /*
-- 
2.31.1.189.g2e36527f23


  parent reply	other threads:[~2021-12-14 22:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14 22:03 [PATCH kcsan 0/29] Kernel Concurrency Sanitizer (KCSAN) updates for v5.17 Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 01/29] kcsan: Refactor reading of instrumented memory Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 02/29] kcsan: Remove redundant zero-initialization of globals Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 03/29] kcsan: Avoid checking scoped accesses from nested contexts Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 04/29] kcsan: Add core support for a subset of weak memory modeling Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 05/29] kcsan: Add core memory barrier instrumentation functions Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 06/29] kcsan, kbuild: Add option for barrier instrumentation only Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 07/29] kcsan: Call scoped accesses reordered in reports Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 08/29] kcsan: Show location access was reordered to Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 09/29] kcsan: Document modeling of weak memory Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 10/29] kcsan: test: Match reordered or normal accesses Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 11/29] kcsan: test: Add test cases for memory barrier instrumentation Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 12/29] kcsan: Ignore GCC 11+ warnings about TSan runtime support Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 13/29] kcsan: selftest: Add test case to check memory barrier instrumentation Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 14/29] locking/barriers, kcsan: Add instrumentation for barriers Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 15/29] locking/barriers, kcsan: Support generic instrumentation Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 16/29] locking/atomics, kcsan: Add instrumentation for barriers Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 17/29] asm-generic/bitops, " Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 18/29] x86/barriers, kcsan: Use generic instrumentation for non-smp barriers Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 19/29] x86/qspinlock, kcsan: Instrument barrier of pv_queued_spin_unlock() Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 20/29] mm, kcsan: Enable barrier instrumentation Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 21/29] sched, kcsan: Enable memory " Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 22/29] objtool, kcsan: Add memory barrier instrumentation to whitelist Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 23/29] objtool, kcsan: Remove memory barrier instrumentation from noinstr Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 24/29] compiler_attributes.h: Add __disable_sanitizer_instrumentation Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 25/29] kcsan: Support WEAK_MEMORY with Clang where no objtool support exists Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 26/29] kcsan: Make barrier tests compatible with lockdep Paul E. McKenney
2021-12-14 22:04 ` [PATCH kcsan 27/29] kcsan: Turn barrier instrumentation into macros Paul E. McKenney
2021-12-14 22:04 ` Paul E. McKenney [this message]
2021-12-14 22:04 ` [PATCH kcsan 29/29] kcsan: Only test clear_bit_unlock_is_negative_byte if arch defines it Paul E. McKenney

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=20211214220439.2236564-28-paulmck@kernel.org \
    --to=paulmck@kernel.org \
    --cc=andreyknvl@google.com \
    --cc=boqun.feng@gmail.com \
    --cc=cai@lca.pw \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@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®