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

"Paul E. McKenney" <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.ports.arm.kernel
Message-ID <5c607693-7fce-4b24-a648-95ab96db6691@paulmck-laptop>
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 <[email protected]>
> 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" <[email protected]>
> Fixes: dd03762ab608 ("arm64: Enable KCSAN")
> Signed-off-by: Marco Elver <[email protected]>
> ---
>  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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.