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

[Paul E. McKenney]

On Mon, Aug 10, 2026 at 04:15:06PM +0100, Will Deacon wrote:
> On Fri, Aug 07, 2026 at 11:44:56AM -0700, Paul E. McKenney wrote:
> > 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.
> 
> Cheers, Paul.
> 
> I've queued it up in the arm64 tree, so please shout if you run into any
> problems.

Thank you, Will!  So far so good on the testing.

							Thanx, Paul