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

[Will Deacon]

Hi Paul,

On Fri, Jul 31, 2026 at 11:39:14AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 31, 2026 at 09:44:16AM -0700, Paul E. McKenney wrote:
> > On Fri, Jul 31, 2026 at 01:51:26PM +0100, Mark Rutland wrote:
> > > Hi Paul,
> > > 
> > > On Thu, Jul 30, 2026 at 04:59:57PM -0700, Paul E. McKenney wrote:
> > > > The .need_resched field can be accessed from both task level and
> > > > from interrrupt handlers, so apply WRITE_ONCE() to the update in
> > > > set_preempt_need_resched().  This also brings arm64 in line with s390
> > > > (which uses atomic operations) and x86 (which uses inline assembly).
> > > > Other architectures avoid this issue via the empty definition in
> > > > include/asm-generic/preempt.h.
> > > > 
> > > > KCSAN located this issue.
> > > 
> > > Do you have the KCSAN splat to hand? Seeing the exact race (and the
> > > relevant reader(s)) would be handy.
> > > 
> > > > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
> > > > Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
> > > > Cc: Will Deacon <will@xxxxxxxxxx>
> > > > Cc: Jinjie Ruan <ruanjinjie@xxxxxxxxxx>
> > > > Cc: Ada Couprie Diaz <ada.coupriediaz@xxxxxxx>
> > > > Cc: <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>
> > > > 
> > > > ---
> > > >  preempt.h |    2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/arch/arm64/include/asm/preempt.h b/arch/arm64/include/asm/preempt.h
> > > > index 932ea4b6204289..610853da140a78 100644
> > > > --- a/arch/arm64/include/asm/preempt.h
> > > > +++ b/arch/arm64/include/asm/preempt.h
> > > > @@ -28,7 +28,7 @@ static inline void preempt_count_set(u64 pc)
> > > >  
> > > >  static inline void set_preempt_need_resched(void)
> > > >  {
> > > > -	current_thread_info()->preempt.need_resched = 0;
> > > > +	WRITE_ONCE(current_thread_info()->preempt.need_resched, 0);
> > > >  }
> > > 
> > > I was under the impression that we only used this in a context where we
> > > couldn't have a nested writer (e.g. within a scheduler IRQ hook, with
> > > IRQs disabled).
> > > 
> > > If we have concurrent writers, this is probably broken regardless of
> > > whether it is single-copy-atomic, and I worry WRITE_ONCE() will mask a
> > > bug.
> > > 
> > > If you can share the KCSAN splat, that'd really help.
> > 
> > Let me regenerate it...
> 
> And please see below.
> 
> > > I think we need READ_ONCE() in test_preempt_need_resched(), but today
> > > that's only used by tracing to determine what to log.
> > 
> > I do have tracing enabled on some of my runs.
> 
> I did build with CONFIG_TRACEPOINTS=y.  Or let me know what sort of tracing
> you are interested in.  Or I can send you this guy from my ARM test system:
> 
> tools/testing/selftests/rcutorture/res/2026.07.31-10.25.08-torture/results-rcutorture-kcsan/TREE01/.config
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> [  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?

Will