[PATCH v3 0/2] rwonce: Introduce {READ,WRITE}_ONCE_THIS_CPU()

[PATCH v3 0/2] rwonce: Introduce {READ,WRITE}_ONCE_THIS_CPU()

[Kunwu Chan]

Hi,

This is a rebase of v2 onto v7.3-rc6 with review tags collected
since v2.

Changes since v2 [1]:
 - Rebased onto v7.3-rc6.
 - Collected Reviewed-by and Acked-by tags.

[1] https://lore.kernel.org/lkml/20261002151757.3605081-1-kunwu.chan@gmail.com/

Changes since v1 [2]:
 - Introduce {READ,WRITE}_ONCE_THIS_CPU() instead of reusing the
   plain variants. (Thomas Gleixner)

 - Expand the commit messages to state the KCSAN rationale. (Thomas
   Gleixner)

[2] https://lore.kernel.org/all/20260920085434.2918331-1-kunwu.chan@gmail.com/
 
Kunwu Chan (2):
  rwonce: Add READ_ONCE_THIS_CPU() and WRITE_ONCE_THIS_CPU()
  timers/nohz: Mark got_idle_tick accesses as same-CPU races

 include/asm-generic/rwonce.h | 11 +++++++++++
 kernel/time/tick-sched.c     |  6 +++---
 2 files changed, 14 insertions(+), 3 deletions(-)


base-commit: a90ee4305c4a5df72c11b31dacfdc76e00fcf78a
-- 
2.43.0

[PATCH v3 1/2] rwonce: Add READ_ONCE_THIS_CPU() and WRITE_ONCE_THIS_CPU()

[Kunwu Chan]

Per-CPU variables are sometimes accessed from different execution
contexts on the same CPU, typically task context and an interrupt or
NMI handler.

A plain READ_ONCE() or WRITE_ONCE() marks such an access as an
intentional race but does not express where the racing accesses are
expected to come from. This distinction allows concurrency tools such
as KCSAN to tell an intentional same-CPU context race apart from an
access that may race across CPUs.

Add READ_ONCE_THIS_CPU() and WRITE_ONCE_THIS_CPU() to identify accesses
to a per-CPU variable which are intended to race only with accesses
from other execution contexts on the same CPU. For now, they are
simple wrappers around READ_ONCE() and WRITE_ONCE(), so generated code
and tool behaviour are unchanged.

Suggested-by: Thomas Gleixner <tglx@kernel.org>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Acked-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Kunwu Chan <kunwu.chan@gmail.com>
---
 include/asm-generic/rwonce.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
index 52b969c7c..4d4e009a4 100644
--- a/include/asm-generic/rwonce.h
+++ b/include/asm-generic/rwonce.h
@@ -61,6 +61,17 @@ do {									\
 	__WRITE_ONCE(x, val);						\
 } while (0)
 
+/*
+ * {READ,WRITE}_ONCE_THIS_CPU() identify accesses to a per-CPU variable
+ * which are intended to race only with accesses from other execution
+ * contexts on the same CPU, e.g. task and interrupt context.
+ *
+ * For now, these are simple wrappers around READ_ONCE() and
+ * WRITE_ONCE().
+ */
+#define READ_ONCE_THIS_CPU(x)		READ_ONCE(x)
+#define WRITE_ONCE_THIS_CPU(x, val)	WRITE_ONCE(x, val)
+
 static __no_sanitize_or_inline
 unsigned long __read_once_word_nocheck(const void *addr)
 {
-- 
2.43.0

Re: [PATCH v3 1/2] rwonce: Add READ_ONCE_THIS_CPU() and WRITE_ONCE_THIS_CPU()

[Arnd Bergmann]

On Wed, Oct 7, 2026, at 04:28, Kunwu Chan wrote:
> Per-CPU variables are sometimes accessed from different execution
> contexts on the same CPU, typically task context and an interrupt or
> NMI handler.
>
> A plain READ_ONCE() or WRITE_ONCE() marks such an access as an
> intentional race but does not express where the racing accesses are
> expected to come from. This distinction allows concurrency tools such
> as KCSAN to tell an intentional same-CPU context race apart from an
> access that may race across CPUs.
>
> Add READ_ONCE_THIS_CPU() and WRITE_ONCE_THIS_CPU() to identify accesses
> to a per-CPU variable which are intended to race only with accesses
> from other execution contexts on the same CPU. For now, they are
> simple wrappers around READ_ONCE() and WRITE_ONCE(), so generated code
> and tool behaviour are unchanged.
>
> Suggested-by: Thomas Gleixner <tglx@kernel.org>
> Suggested-by: Paul E. McKenney <paulmck@kernel.org>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Acked-by: Frederic Weisbecker <frederic@kernel.org>
> Signed-off-by: Kunwu Chan <kunwu.chan@gmail.com>

No objections here, but since I missed the background, I don't
see what a future implementation of the new macros might do
that is different from the existing macros, maybe you can still
clarify that.

For taking this through something other than my asm-generic tree:

Acked-by: Arnd Bergmann <arnd@arndb.de>

[PATCH v3 2/2] timers/nohz: Mark got_idle_tick accesses as same-CPU races

[Kunwu Chan]

got_idle_tick is a per-CPU flag set by the tick interrupt handler in
tick_sched_do_timer() and read and cleared by the idle path in
tick_nohz_idle_got_tick().  The flag is intentionally accessed without
ordering or locking; a concurrent set can be overwritten by the clear.

Use WRITE_ONCE_THIS_CPU() and READ_ONCE_THIS_CPU() to identify these
as intentional races between execution contexts on the same CPU,
rather than accesses that may race across CPUs.

Suggested-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Kunwu Chan <kunwu.chan@gmail.com>
---
 kernel/time/tick-sched.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 6c3fea386..a136bb247 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -269,7 +269,7 @@ static void tick_sched_do_timer(struct tick_sched *ts, ktime_t now)
 	}
 
 	if (tick_sched_flag_test(ts, TS_FLAG_INIDLE))
-		ts->got_idle_tick = 1;
+		WRITE_ONCE_THIS_CPU(ts->got_idle_tick, 1);
 }
 
 static void tick_sched_handle(struct tick_sched *ts, struct pt_regs *regs)
@@ -1248,8 +1248,8 @@ bool tick_nohz_idle_got_tick(void)
 {
 	struct tick_sched *ts = this_cpu_ptr(&tick_cpu_sched);
 
-	if (ts->got_idle_tick) {
-		ts->got_idle_tick = 0;
+	if (READ_ONCE_THIS_CPU(ts->got_idle_tick)) {
+		WRITE_ONCE_THIS_CPU(ts->got_idle_tick, 0);
 		return true;
 	}
 	return false;
-- 
2.43.0