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 >