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

[Will Deacon]

Hi Marco,

Thanks for the help.

On Fri, Aug 07, 2026 at 02:21:39PM +0200, Marco Elver wrote:
> On Fri, 7 Aug 2026 at 14:06, Will Deacon <will@xxxxxxxxxx> wrote:
> > On Thu, Aug 06, 2026 at 10:25:37AM -0700, Paul E. McKenney wrote:
> > > On Thu, Aug 06, 2026 at 12:58:40PM +0100, Will Deacon wrote:
> > > > On Fri, Jul 31, 2026 at 11:39:14AM -0700, Paul E. McKenney wrote:
> > > > > [  738.696166] BUG: KCSAN: data-race in __delay / set_need_resched_current
> > > > > [  738.696184]
> > > > > [  738.696188] read (marked) to 0xffff000005899b48 of 8 bytes by interrupt on cpu 8:
> > > > > [  738.696198]  __delay+0xb0/0x378
> > > > > [  738.696212]  __udelay+0x4c/0x60
> > > > > [  738.696225]  kcsan_setup_watchpoint+0x3b4/0x820
> > > > > [  738.696238]  __tsan_unaligned_write4+0x228/0x26c
> > > > > [  738.696249]  set_need_resched_current+0x138/0x1a8
> > > > > [  738.696260]  rcu_exp_handler+0x418/0x4a0
> > > > > [  738.696273]  __flush_smp_call_function_queue+0x36c/0x4a0
> > > > > [  738.696288]  generic_smp_call_function_single_interrupt+0x20/0x30
> > > >
> > > > This is a bit weird -- it looks like the read is occuring from within
> > > > kcsan itself?
> > >
> > > Ah, you are right, as part of KCSAN's software watchpoints.
> > >
> > > What do you suggest?
> >
> > I suppose we could add some __no_kcsan annotations to everything that is
> > called from the KCSAN implementation but it feels error-prone and could
> > hide races exposed by other callers.
> >
> > I've added the KCSAN folks to see if they have any other ideas; it looks
> > like the sort of thing you'd expect them to have encountered already.
> 
> Most of KCSAN's internals are not instrumented, but do call out to
> some instrumented bits where that's safe. In this case, it looks like
> a real data race, even though the access comes from __delay that was
> called by KCSAN, I don't think it's any less valid.

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.

Will