The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Will Deacon <will@kernel.org>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	dvyukov@google.com, Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Jinjie Ruan <ruanjinjie@huawei.com>,
	Ada Couprie Diaz <ada.coupriediaz@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com
Subject: Re: [PATCH RFC] arm64: Mark set_preempt_need_resched() access to .need_resched
Date: Fri, 7 Aug 2026 13:45:28 +0000	[thread overview]
Message-ID: <anXheKZ7zKNw1oD_@elver.google.com> (raw)
In-Reply-To: <anXbTwhaWZCIxxTg@willie-the-truck>

On Fri, Aug 07, 2026 at 02:19PM +0100, Will Deacon wrote:
[...]
> Ok, but then I don't understand how these accesses can race. They appear
> to be on the same CPU, in the same IPI handler.

The only way this could happen is with an NMI, but that's not the case
here? I should have looked at the 2nd stack trace, and it seems to be
clear that this is a false positive: KCSAN sets up a watchpoint on an
address that is also accessed by __delay.

One problem with disabling KCSAN in this CPU's context is that we'd fail
to detect data races from nested interrupts.

So yes, the best way forward is to disable KCSAN in the delay
implementation. And I recall doing this for x86, which has this:

	[arch/x86/lib/Makefile]
	...

	# KCSAN uses udelay for introducing watchpoint delay; avoid recursion.
	KCSAN_SANITIZE_delay.o := n

So let's do this for arm64, too. Sorry for the noise.

------ >8 ------

From cfea3a0c12b2e685ce04c28b1bd207f0e4c05a56 Mon Sep 17 00:00:00 2001
From: Marco Elver <elver@google.com>
Date: Fri, 7 Aug 2026 13:37:32 +0000
Subject: [PATCH] arm64: Disable KCSAN instrumentation in delay.o

KCSAN relies on udelay() for injecting delays. To avoid recursively
triggering a watchpoint, where KCSAN sets up watchpoint on an address
that is accessed by udelay() in the same thread, disable instrumentation
in arm64's delay implementation.

Paul found a manifestation of this as follows:

| BUG: KCSAN: data-race in __delay / set_need_resched_current
|
| read (marked) to 0xffff000005899b48 of 8 bytes by interrupt on cpu 8:
|  __delay+0xb0/0x378
|  __udelay+0x4c/0x60
|  kcsan_setup_watchpoint+0x3b4/0x820
|  __tsan_unaligned_write4+0x228/0x26c
|  set_need_resched_current+0x138/0x1a8
|  rcu_exp_handler+0x418/0x4a0
|  __flush_smp_call_function_queue+0x36c/0x4a0
|  generic_smp_call_function_single_interrupt+0x20/0x30
|  ipi_handler+0xec/0x558
|  handle_percpu_devid_irq+0x220/0x2a0
|  generic_handle_domain_irq+0x84/0xb4
|  gic_handle_irq+0x64/0x144
|  call_on_irq_stack+0x30/0x48
|  do_interrupt_handler+0x80/0xb8
|  el1_interrupt+0x3c/0x60
|  el1h_64_irq_handler+0x18/0x24
|  el1h_64_irq+0x6c/0x70
|  smp_call_function_single+0x18c/0x25c
|  sync_rcu_exp_select_node_cpus+0x534/0x8bc
|  rcu_exp_sel_wait_wake+0x358/0xef4
|  wait_rcu_exp_gp+0x30/0x44
|  kthread_worker_fn+0x1b4/0x5dc
|  kthread+0x1d8/0x204
|  ret_from_fork+0x10/0x20
|
| write to 0xffff000005899b4c of 4 bytes by interrupt on cpu 8:
|  set_need_resched_current+0x138/0x1a8
|  [...]

This matches what is already done in arch/x86/lib/Makefile.

Reported-by: "Paul E. McKenney" <paulmck@kernel.org>
Fixes: dd03762ab608 ("arm64: Enable KCSAN")
Signed-off-by: Marco Elver <elver@google.com>
---
 arch/arm64/lib/Makefile | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 448c917494f3..b33e1ca4a781 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -1,4 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
+
+# KCSAN uses udelay for introducing watchpoint delay; avoid recursion.
+KCSAN_SANITIZE_delay.o := n
+
 lib-y		:= clear_user.o delay.o copy_from_user.o		\
 		   copy_to_user.o copy_page.o				\
 		   clear_page.o csum.o insn.o memchr.o memcpy.o		\
-- 
2.55.0.654.g21b8a5bc05-goog


  reply	other threads:[~2026-08-07 13:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 23:59 [PATCH RFC] arm64: Mark set_preempt_need_resched() access to .need_resched Paul E. McKenney
2026-07-31 12:51 ` Mark Rutland
2026-07-31 16:44   ` Paul E. McKenney
2026-07-31 18:39     ` Paul E. McKenney
2026-08-06 11:58       ` Will Deacon
2026-08-06 17:25         ` Paul E. McKenney
2026-08-07 12:06           ` Will Deacon
2026-08-07 12:21             ` Marco Elver
2026-08-07 13:19               ` Will Deacon
2026-08-07 13:45                 ` Marco Elver [this message]
2026-08-07 18:44                   ` 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=anXheKZ7zKNw1oD_@elver.google.com \
    --to=elver@google.com \
    --cc=ada.coupriediaz@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dvyukov@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ruanjinjie@huawei.com \
    --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