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

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

[Paul E. McKenney]

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.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>

---
 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);
 }
 
 static inline void clear_preempt_need_resched(void)

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

[Mark Rutland]

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@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> Cc: <linux-arm-kernel@lists.infradead.org>
> 
> ---
>  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.

I think we need READ_ONCE() in test_preempt_need_resched(), but today
that's only used by tracing to determine what to log.

Mark.

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

[Paul E. McKenney]

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@kernel.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> > Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> > Cc: <linux-arm-kernel@lists.infradead.org>
> > 
> > ---
> >  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...

> 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.

							Thanx, Paul

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

[Paul E. McKenney]

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@kernel.org>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <will@kernel.org>
> > > Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> > > Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> > > Cc: <linux-arm-kernel@lists.infradead.org>
> > > 
> > > ---
> > >  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
[  738.696302]  ipi_handler+0xec/0x558
[  738.696314]  handle_percpu_devid_irq+0x220/0x2a0
[  738.696325]  generic_handle_domain_irq+0x84/0xb4
[  738.696339]  gic_handle_irq+0x64/0x144
[  738.696349]  call_on_irq_stack+0x30/0x48
[  738.696363]  do_interrupt_handler+0x80/0xb8
[  738.696374]  el1_interrupt+0x3c/0x60
[  738.696385]  el1h_64_irq_handler+0x18/0x24
[  738.696397]  el1h_64_irq+0x6c/0x70
[  738.696406]  smp_call_function_single+0x18c/0x25c
[  738.696419]  sync_rcu_exp_select_node_cpus+0x534/0x8bc
[  738.696433]  rcu_exp_sel_wait_wake+0x358/0xef4
[  738.696445]  wait_rcu_exp_gp+0x30/0x44
[  738.696458]  kthread_worker_fn+0x1b4/0x5dc
[  738.696472]  kthread+0x1d8/0x204
[  738.696483]  ret_from_fork+0x10/0x20
[  738.696496]
[  738.696499] write to 0xffff000005899b4c of 4 bytes by interrupt on cpu 8:
[  738.696508]  set_need_resched_current+0x138/0x1a8
[  738.696519]  rcu_exp_handler+0x418/0x4a0
[  738.696532]  __flush_smp_call_function_queue+0x36c/0x4a0
[  738.696545]  generic_smp_call_function_single_interrupt+0x20/0x30
[  738.696559]  ipi_handler+0xec/0x558
[  738.696570]  handle_percpu_devid_irq+0x220/0x2a0
[  738.696580]  generic_handle_domain_irq+0x84/0xb4
[  738.696593]  gic_handle_irq+0x64/0x144
[  738.696602]  call_on_irq_stack+0x30/0x48
[  738.696615]  do_interrupt_handler+0x80/0xb8
[  738.696625]  el1_interrupt+0x3c/0x60
[  738.696636]  el1h_64_irq_handler+0x18/0x24
[  738.696648]  el1h_64_irq+0x6c/0x70
[  738.696657]  smp_call_function_single+0x18c/0x25c
[  738.696670]  sync_rcu_exp_select_node_cpus+0x534/0x8bc
[  738.696684]  rcu_exp_sel_wait_wake+0x358/0xef4
[  738.696696]  wait_rcu_exp_gp+0x30/0x44
[  738.696710]  kthread_worker_fn+0x1b4/0x5dc
[  738.696722]  kthread+0x1d8/0x204
[  738.696735]  ret_from_fork+0x10/0x20
[  738.696748]
[  738.696752] no locks held by rcu_exp_gp_kthr/19.
[  738.696759] irq event stamp: 1427532
[  738.717431] hardirqs last  enabled at (1427531): [<ffffb4646136fbfc>] _raw_spin_unlock_irqrestore+0x48/0xa0
[  738.718368] hardirqs last disabled at (1427532): [<ffffb46461357d80>] el1_interrupt+0x28/0x60
[  738.719022] softirqs last  enabled at (1427262): [<ffffb4645f773ac0>] handle_softirqs+0x508/0x55c
[  738.719776] softirqs last disabled at (1427255): [<ffffb4645f610b4c>] __do_softirq+0x14/0x20
[  738.720431]
[  738.720436] Reported by Kernel Concurrency Sanitizer on:
[  738.720444] CPU: 8 UID: 0 PID: 19 Comm: rcu_exp_gp_kthr Not tainted 7.2.0-rc3-00125-g1a23334a317e #14393 PREEMPT
[  738.720458] Hardware name: linux,dummy-virt (DT)
[  738.720464] ==================================================================

(gdb) l*__delay+0xb0
0xffff800081d11084 is in __delay (./arch/arm64/include/asm/preempt.h:61).
56      }
57
58      static inline bool __preempt_count_dec_and_test(void)
59      {
60              struct thread_info *ti = current_thread_info();
61              u64 pc = READ_ONCE(ti->preempt_count);
62
63              /* Update only the count field, leaving need_resched unchanged */
64              WRITE_ONCE(ti->preempt.count, --pc);
65
(gdb) l*set_need_resched_current+0x138
0xffff80008028b580 is in set_need_resched_current (./arch/arm64/include/asm/preempt.h:31).
26              task_thread_info(p)->preempt_count = PREEMPT_DISABLED; \
27      } while (0)
28
29      static inline void set_preempt_need_resched(void)
30      {
31              current_thread_info()->preempt.need_resched = 0;
32      }
33
34      static inline void clear_preempt_need_resched(void)
35      {

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@kernel.org>
> > > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > > Cc: Will Deacon <will@kernel.org>
> > > > Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> > > > Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> > > > Cc: <linux-arm-kernel@lists.infradead.org>
> > > > 
> > > > ---
> > > >  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

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

[Paul E. McKenney]

On Thu, Aug 06, 2026 at 12:58:40PM +0100, Will Deacon wrote:
> 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@kernel.org>
> > > > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > > > Cc: Will Deacon <will@kernel.org>
> > > > > Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> > > > > Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> > > > > Cc: <linux-arm-kernel@lists.infradead.org>
> > > > > 
> > > > > ---
> > > > >  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?

Ah, you are right, as part of KCSAN's software watchpoints.

What do you suggest?

							Thanx, Paul

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

[Will Deacon]

[+KCSAN maintainers]

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:
> > > 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:
> > > > > 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@kernel.org>
> > > > > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > > > > Cc: Will Deacon <will@kernel.org>
> > > > > > Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> > > > > > Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> > > > > > Cc: <linux-arm-kernel@lists.infradead.org>
> > > > > > 
> > > > > > ---
> > > > > >  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?
> 
> 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.

Cheers,

Will

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

[Marco Elver]

On Fri, 7 Aug 2026 at 14:06, Will Deacon <will@kernel.org> wrote:
>
> [+KCSAN maintainers]
>
> 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:
> > > > 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:
> > > > > > 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@kernel.org>
> > > > > > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > > > > > Cc: Will Deacon <will@kernel.org>
> > > > > > > Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> > > > > > > Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> > > > > > > Cc: <linux-arm-kernel@lists.infradead.org>
> > > > > > >
> > > > > > > ---
> > > > > > >  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?
> >
> > 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.

I have a fix pending [1] (queued for next merge window), however,
which would have suppressed this one.

[1] https://lore.kernel.org/all/20260722212700.828037-1-elver@google.com/

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@kernel.org> 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

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

[Marco Elver]

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.

------ >8 ------

From cfea3a0c12b2e685ce04c28b1bd207f0e4c05a56 Mon Sep 17 00:00:00 2001
From: Marco Elver <elver@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@kernel.org>
Fixes: dd03762ab608 ("arm64: Enable KCSAN")
Signed-off-by: Marco Elver <elver@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

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

[Paul E. McKenney]

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@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@kernel.org>
> Fixes: dd03762ab608 ("arm64: Enable KCSAN")
> Signed-off-by: Marco Elver <elver@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
>