[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