[PATCH RFC] arm64: Mark set_preempt_need_resched() access to .need_resched

Paul E. McKenney paulmck at kernel.org
Fri Aug 7 11:44:56 PDT 2026


On Fri, Aug 07, 2026 at 01:45:28PM +0000, Marco Elver wrote:
> 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.

Thank you both!

I will revert my arm64-specific patch and apply this one.  Testing will
take some time, and I will get you know how it goes.

							Thanx, Paul

> ------ >8 ------
> 
> >From cfea3a0c12b2e685ce04c28b1bd207f0e4c05a56 Mon Sep 17 00:00:00 2001
> From: Marco Elver <elver at 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 at kernel.org>
> Fixes: dd03762ab608 ("arm64: Enable KCSAN")
> Signed-off-by: Marco Elver <elver at 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
> 



More information about the linux-arm-kernel mailing list