[PATCH RFC 0/9] Fix data races on hrtimer_sleeper ->task field

[PATCH RFC 0/9] Fix data races on hrtimer_sleeper ->task field

[Paul E. McKenney]

Hello!

In CONFIG_KCSAN_STRICT=y mode, KCSAN finds data races on the
hrtimer_sleeper structure's ->task field.  This field is used to indicate
owner of this structure, and also to signal the sleeper that the sleep
is over through use of a store of NULL.

Because access to the ->task field is open-coded across several kernel
subsystems, this series creates accessor functions creatively named
hrtimer_sleeper_task_get() and hrtimer_sleeper_task_set(), and uses
these throughout.

A key goal of this and similar serieses is to reduce KCSAN noise in
strict mode so that new data races are more visible.

The series is as follows:

1.	hrtimer: Mark data-racy accesses to hrtimer_sleeper ->task field.

2.	aio: Use accessor for hrtimer_sleeper ->task field.

3.	wait: Use accessor for hrtimer_sleeper ->task field.

4.	io-uring: Use accessor for hrtimer_sleeper ->task field.

5.	futex: Use accessor for hrtimer_sleeper ->task field in waitwake.c.

6.	timers: Use accessor for hrtimer_sleeper ->task field in
	sleep_timeout.c.

7.	net: pktgen: Use accessor for hrtimer_sleeper ->task field.

8.	rtmutex: Use accessor for hrtimer_sleeper ->task field.

9.	futex: Use accessor for hrtimer_sleeper ->task field in requeue.

						Thanx, Paul

------------------------------------------------------------------------

 fs/aio.c                    |    2 +-
 include/linux/hrtimer.h     |    8 ++++++++
 include/linux/wait.h        |    2 +-
 io_uring/rw.c               |    2 +-
 kernel/futex/requeue.c      |    2 +-
 kernel/futex/waitwake.c     |    8 ++++----
 kernel/locking/rtmutex.c    |    2 +-
 kernel/time/hrtimer.c       |   14 +++++++-------
 kernel/time/sleep_timeout.c |    4 ++--
 net/core/pktgen.c           |    4 ++--
 10 files changed, 28 insertions(+), 20 deletions(-)

[PATCH RFC 1/9] hrtimer: Mark data-racy accesses to hrtimer_sleeper ->task field

[Paul E. McKenney]

The hrtimer_sleeper structure's ->task field is used as a flag to indicate
that the associated hrtimer has expired.  This means that the hrtimer
handler can be storing to this field while other code is loading from it
to check for expiry.  Note that additional races appear for hrtimers that
can be restarted, which could be argued to be a user error.  However,
that is no reason to let the compiler introduce additional confusion.

Therefore, mark data-racy accesses to the hrtimer_sleeper ->task field
using READ_ONCE() (using a new hrtimer_sleeper_task_get() access function)
and WRITE_ONCE() (using a new hrtimer_sleeper_task_set() access function).

KCSAN located this issue.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
---
 include/linux/hrtimer.h |  8 ++++++++
 kernel/time/hrtimer.c   | 14 +++++++-------
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 6862dea0acc52f..838ea7bce99c1d 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -350,6 +350,14 @@ extern int schedule_hrtimeout_range_clock(ktime_t *expires,
 					  const enum hrtimer_mode mode,
 					  clockid_t clock_id);
 extern int schedule_hrtimeout(ktime_t *expires, const enum hrtimer_mode mode);
+static inline struct task_struct *hrtimer_sleeper_task_get(struct hrtimer_sleeper *sl)
+{
+	return READ_ONCE(sl->task);
+}
+static inline void hrtimer_sleeper_task_set(struct hrtimer_sleeper *sl, struct task_struct *t)
+{
+	WRITE_ONCE(sl->task, t);
+}
 
 /* Soft interrupt function to run the hrtimer queues: */
 extern void hrtimer_run_queues(void);
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 313dcea127fe48..84ea341a6efcc4 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -2286,9 +2286,9 @@ void hrtimer_run_queues(void)
 static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer)
 {
 	struct hrtimer_sleeper *t = container_of(timer, struct hrtimer_sleeper, timer);
-	struct task_struct *task = t->task;
+	struct task_struct *task = hrtimer_sleeper_task_get(t);
 
-	t->task = NULL;
+	hrtimer_sleeper_task_set(t, NULL);
 	if (task)
 		wake_up_process(task);
 
@@ -2317,7 +2317,7 @@ void hrtimer_sleeper_start_expires(struct hrtimer_sleeper *sl, enum hrtimer_mode
 
 	/* If already expired, clear the task pointer and set current state to running */
 	if (!hrtimer_start_expires_user(&sl->timer, mode)) {
-		sl->task = NULL;
+		hrtimer_sleeper_task_set(sl, NULL);
 		__set_current_state(TASK_RUNNING);
 	}
 }
@@ -2351,7 +2351,7 @@ static void __hrtimer_setup_sleeper(struct hrtimer_sleeper *sl, clockid_t clock_
 	}
 
 	__hrtimer_setup(&sl->timer, hrtimer_wakeup, clock_id, mode);
-	sl->task = current;
+	hrtimer_sleeper_task_set(sl, current);
 }
 
 /**
@@ -2395,17 +2395,17 @@ static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode mod
 		set_current_state(TASK_INTERRUPTIBLE|TASK_FREEZABLE);
 		hrtimer_sleeper_start_expires(t, mode);
 
-		if (likely(t->task))
+		if (likely(hrtimer_sleeper_task_get(t)))
 			schedule();
 
 		hrtimer_cancel(&t->timer);
 		mode = HRTIMER_MODE_ABS;
 
-	} while (t->task && !signal_pending(current));
+	} while (hrtimer_sleeper_task_get(t) && !signal_pending(current));
 
 	__set_current_state(TASK_RUNNING);
 
-	if (!t->task)
+	if (!hrtimer_sleeper_task_get(t))
 		return 0;
 
 	restart = &current->restart_block;
-- 
2.40.1

Re: [PATCH RFC 1/9] hrtimer: Mark data-racy accesses to hrtimer_sleeper ->task field

[Dmitry Ilvokhin]

On Thu, Jul 30, 2026 at 05:40:11PM -0700, Paul E. McKenney wrote:
> The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> that the associated hrtimer has expired.  This means that the hrtimer
> handler can be storing to this field while other code is loading from it
> to check for expiry.  Note that additional races appear for hrtimers that
> can be restarted, which could be argued to be a user error.  However,
> that is no reason to let the compiler introduce additional confusion.
> 
> Therefore, mark data-racy accesses to the hrtimer_sleeper ->task field
> using READ_ONCE() (using a new hrtimer_sleeper_task_get() access function)
> and WRITE_ONCE() (using a new hrtimer_sleeper_task_set() access function).
> 
> KCSAN located this issue.
> 
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

Reviewed-by: Dmitry Ilvokhin <d@ilvokhin.com>

[PATCH RFC 2/9] aio: Use accessor for hrtimer_sleeper ->task field

[Paul E. McKenney]

The hrtimer_sleeper structure's ->task field is used as a flag to indicate
that the associated hrtimer has expired.  This means that the hrtimer
handler can be storing to this field while other code is loading from it
to check for expiry.  Note that additional races appear for hrtimers that
can be restarted, which could be argued to be a user error.  However, that
is no reason to let the compiler introduce additional confusion, and to
this end, the hrtimer_sleeper_task_get() was introduced, use of which also
has the benefit of avoiding open-code access to hrtimer_sleeper innards.

KCSAN located this issue.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: <linux-aio@kvack.org>
Cc: <linux-fsdevel@vger.kernel.org>
---
 fs/aio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/aio.c b/fs/aio.c
index f57fa21a250353..e8cd65fce41eba 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1402,7 +1402,7 @@ static long read_events(struct kioctx *ctx, long min_nr, long nr,
 		w.min_nr = min_nr - ret;
 
 		ret2 = prepare_to_wait_event(&ctx->wait, &w.w, TASK_INTERRUPTIBLE);
-		if (!ret2 && !t.task)
+		if (!ret2 && !hrtimer_sleeper_task_get(&t))
 			ret2 = -ETIME;
 
 		if (aio_read_events(ctx, min_nr, nr, event, &ret) || ret2)
-- 
2.40.1

Re: [PATCH RFC 2/9] aio: Use accessor for hrtimer_sleeper ->task field

[Jan Kara]

On Thu 30-07-26 17:40:12, Paul E. McKenney wrote:
> The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> that the associated hrtimer has expired.  This means that the hrtimer
> handler can be storing to this field while other code is loading from it
> to check for expiry.  Note that additional races appear for hrtimers that
> can be restarted, which could be argued to be a user error.  However, that
> is no reason to let the compiler introduce additional confusion, and to
> this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> 
> KCSAN located this issue.
> 
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Cc: Benjamin LaHaise <bcrl@kvack.org>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: <linux-aio@kvack.org>
> Cc: <linux-fsdevel@vger.kernel.org>

Looks good. Feel free to add:

Acked-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/aio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/aio.c b/fs/aio.c
> index f57fa21a250353..e8cd65fce41eba 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -1402,7 +1402,7 @@ static long read_events(struct kioctx *ctx, long min_nr, long nr,
>  		w.min_nr = min_nr - ret;
>  
>  		ret2 = prepare_to_wait_event(&ctx->wait, &w.w, TASK_INTERRUPTIBLE);
> -		if (!ret2 && !t.task)
> +		if (!ret2 && !hrtimer_sleeper_task_get(&t))
>  			ret2 = -ETIME;
>  
>  		if (aio_read_events(ctx, min_nr, nr, event, &ret) || ret2)
> -- 
> 2.40.1
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH RFC 2/9] aio: Use accessor for hrtimer_sleeper ->task field

[Christian Brauner]

On 2026-07-30 17:40 -0700, Paul E. McKenney wrote:
> The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> that the associated hrtimer has expired.  This means that the hrtimer
> handler can be storing to this field while other code is loading from it
> to check for expiry.  Note that additional races appear for hrtimers that
> can be restarted, which could be argued to be a user error.  However, that
> is no reason to let the compiler introduce additional confusion, and to
> this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> 
> KCSAN located this issue.
> 
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Cc: Benjamin LaHaise <bcrl@kvack.org>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: <linux-aio@kvack.org>
> Cc: <linux-fsdevel@vger.kernel.org>
> ---

Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>

Re: [PATCH RFC 2/9] aio: Use accessor for hrtimer_sleeper ->task field

[Paul E. McKenney]

On Fri, Jul 31, 2026 at 02:57:57PM +0200, Christian Brauner wrote:
> On 2026-07-30 17:40 -0700, Paul E. McKenney wrote:
> > The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> > that the associated hrtimer has expired.  This means that the hrtimer
> > handler can be storing to this field while other code is loading from it
> > to check for expiry.  Note that additional races appear for hrtimers that
> > can be restarted, which could be argued to be a user error.  However, that
> > is no reason to let the compiler introduce additional confusion, and to
> > this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> > has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> > 
> > KCSAN located this issue.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > Cc: Benjamin LaHaise <bcrl@kvack.org>
> > Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> > Cc: Christian Brauner <brauner@kernel.org>
> > Cc: Jan Kara <jack@suse.cz>
> > Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
> > Cc: Frederic Weisbecker <frederic@kernel.org>
> > Cc: Thomas Gleixner <tglx@kernel.org>
> > Cc: <linux-aio@kvack.org>
> > Cc: <linux-fsdevel@vger.kernel.org>
> > ---
> 
> Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>

Thank you both, and I will apply your tags on my next rebase.

							Thanx, Paul

[PATCH RFC 3/9] wait: Use accessor for hrtimer_sleeper ->task field

[Paul E. McKenney]

The hrtimer_sleeper structure's ->task field is used as a flag to indicate
that the associated hrtimer has expired.  This means that the hrtimer
handler can be storing to this field while other code is loading from it
to check for expiry.  Note that additional races appear for hrtimers that
can be restarted, which could be argued to be a user error.  However, that
is no reason to let the compiler introduce additional confusion, and to
this end, the hrtimer_sleeper_task_get() was introduced, use of which also
has the benefit of avoiding open-code access to hrtimer_sleeper innards.

Therefore, apply this accessor to the __wait_event_hrtimeout() macro.

KCSAN located this issue.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ben Segall <bsegall@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
---
 include/linux/wait.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/wait.h b/include/linux/wait.h
index dce055e6add390..00cdce75837e72 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -556,7 +556,7 @@ do {										\
 	}									\
 										\
 	__ret = ___wait_event(wq_head, condition, state, 0, 0,			\
-		if (!__t.task) {						\
+		if (!hrtimer_sleeper_task_get(&__t)) {				\
 			__ret = -ETIME;						\
 			break;							\
 		}								\
-- 
2.40.1

[PATCH RFC 4/9] io-uring/rw: Use accessor for hrtimer_sleeper ->task field

[Paul E. McKenney]

The hrtimer_sleeper structure's ->task field is used as a flag to indicate
that the associated hrtimer has expired.  This means that the hrtimer
handler can be storing to this field while other code is loading from it
to check for expiry.  Note that additional races appear for hrtimers that
can be restarted, which could be argued to be a user error.  However, that
is no reason to let the compiler introduce additional confusion, and to
this end, the hrtimer_sleeper_task_get() was introduced, use of which also
has the benefit of avoiding open-code access to hrtimer_sleeper innards.

Therefore, apply this accessor to the io_hybrid_iopoll_delay() function.

KCSAN located this issue.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: <io-uring@vger.kernel.org>
---
 io_uring/rw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/io_uring/rw.c b/io_uring/rw.c
index 63b6519e498cd7..4afbc3ceea0bb4 100644
--- a/io_uring/rw.c
+++ b/io_uring/rw.c
@@ -1291,7 +1291,7 @@ static u64 io_hybrid_iopoll_delay(struct io_ring_ctx *ctx, struct io_kiocb *req)
 	set_current_state(TASK_INTERRUPTIBLE);
 	hrtimer_sleeper_start_expires(&timer, mode);
 
-	if (timer.task)
+	if (hrtimer_sleeper_task_get(&timer))
 		io_schedule();
 
 	hrtimer_cancel(&timer.timer);
-- 
2.40.1

Re: [PATCH RFC 4/9] io-uring/rw: Use accessor for hrtimer_sleeper ->task field

[Jens Axboe]

On 7/30/26 6:40 PM, Paul E. McKenney wrote:
> The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> that the associated hrtimer has expired.  This means that the hrtimer
> handler can be storing to this field while other code is loading from it
> to check for expiry.  Note that additional races appear for hrtimers that
> can be restarted, which could be argued to be a user error.  However, that
> is no reason to let the compiler introduce additional confusion, and to
> this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> 
> Therefore, apply this accessor to the io_hybrid_iopoll_delay() function.

Seems fine to me, but for some reason you didn't CC all the people on
the series. Hence I don't know if each can stand on its own. A quick
grep tells me that, no, that is not the case, as
hrtimer_sleeper_task_get() isn't a thing in the tree right now.

That's a slight nudge to please don't do partial CCs, it's impossible to
tell without needing to dig further.

-- 
Jens Axboe

Re: [PATCH RFC 4/9] io-uring/rw: Use accessor for hrtimer_sleeper ->task field

[Paul E. McKenney]

On Fri, Jul 31, 2026 at 09:03:29AM -0600, Jens Axboe wrote:
> On 7/30/26 6:40 PM, Paul E. McKenney wrote:
> > The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> > that the associated hrtimer has expired.  This means that the hrtimer
> > handler can be storing to this field while other code is loading from it
> > to check for expiry.  Note that additional races appear for hrtimers that
> > can be restarted, which could be argued to be a user error.  However, that
> > is no reason to let the compiler introduce additional confusion, and to
> > this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> > has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> > 
> > Therefore, apply this accessor to the io_hybrid_iopoll_delay() function.
> 
> Seems fine to me, but for some reason you didn't CC all the people on
> the series. Hence I don't know if each can stand on its own. A quick
> grep tells me that, no, that is not the case, as
> hrtimer_sleeper_task_get() isn't a thing in the tree right now.
> 
> That's a slight nudge to please don't do partial CCs, it's impossible to
> tell without needing to dig further.

Good point, and apologies!

However, in this case I would have overrun the CC limit.  Would it suffice
to just add all the lists (in your case, "Cc: <io-uring@vger.kernel.org>")
on all the commits?

							Thanx, Paul

[PATCH RFC 5/9] futex: Use accessor for hrtimer_sleeper ->task field in waitwake.c

[Paul E. McKenney]

The hrtimer_sleeper structure's ->task field is used as a flag to indicate
that the associated hrtimer has expired.  This means that the hrtimer
handler can be storing to this field while other code is loading from it
to check for expiry.  Note that additional races appear for hrtimers that
can be restarted, which could be argued to be a user error.  However, that
is no reason to let the compiler introduce additional confusion, and to
this end, the hrtimer_sleeper_task_get() was introduced, use of which also
has the benefit of avoiding open-code access to hrtimer_sleeper innards.

Therefore, apply this accessor to kernel/futex/waitwake.c.

KCSAN located this issue.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: "André Almeida" <andrealmeid@igalia.com>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
---
 kernel/futex/waitwake.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/futex/waitwake.c b/kernel/futex/waitwake.c
index d4483d15d30a5d..cf18309e577030 100644
--- a/kernel/futex/waitwake.c
+++ b/kernel/futex/waitwake.c
@@ -383,7 +383,7 @@ void futex_do_wait(struct futex_q *q, struct hrtimer_sleeper *timeout)
 		 * flagged for rescheduling. Only call schedule if there
 		 * is no timeout, or if it has yet to expire.
 		 */
-		if (!timeout || timeout->task)
+		if (!timeout || hrtimer_sleeper_task_get(timeout))
 			schedule();
 	}
 	__set_current_state(TASK_RUNNING);
@@ -539,7 +539,7 @@ int futex_wait_multiple_setup(struct futex_vector *vs, int count, int *woken)
 static void futex_sleep_multiple(struct futex_vector *vs, unsigned int count,
 				 struct hrtimer_sleeper *to)
 {
-	if (to && !to->task)
+	if (to && !hrtimer_sleeper_task_get(to))
 		return;
 
 	for (; count; count--, vs++) {
@@ -590,7 +590,7 @@ int futex_wait_multiple(struct futex_vector *vs, unsigned int count,
 		if (ret >= 0)
 			return ret;
 
-		if (to && !to->task)
+		if (to && !hrtimer_sleeper_task_get(to))
 			return -ETIMEDOUT;
 		else if (signal_pending(current))
 			return -ERESTARTSYS;
@@ -725,7 +725,7 @@ int __futex_wait(u32 __user *uaddr, unsigned int flags, u32 val,
 	if (!futex_unqueue(&q))
 		return 0;
 
-	if (to && !to->task)
+	if (to && !hrtimer_sleeper_task_get(to))
 		return -ETIMEDOUT;
 
 	/*
-- 
2.40.1

Re: [PATCH RFC 5/9] futex: Use accessor for hrtimer_sleeper ->task field in waitwake.c

[André Almeida]

Em 30/07/2026 21:40, Paul E. McKenney escreveu:
> The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> that the associated hrtimer has expired.  This means that the hrtimer
> handler can be storing to this field while other code is loading from it
> to check for expiry.  Note that additional races appear for hrtimers that
> can be restarted, which could be argued to be a user error.  However, that
> is no reason to let the compiler introduce additional confusion, and to
> this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> 
> Therefore, apply this accessor to kernel/futex/waitwake.c.
> 
> KCSAN located this issue.
> 
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Darren Hart <dvhart@infradead.org>
> Cc: Davidlohr Bueso <dave@stgolabs.net>
> Cc: "André Almeida" <andrealmeid@igalia.com>
> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: André Almeida <andrealmeid@igalia.com>

Re: [PATCH RFC 5/9] futex: Use accessor for hrtimer_sleeper ->task field in waitwake.c

[Dmitry Ilvokhin]

On Thu, Jul 30, 2026 at 05:40:15PM -0700, Paul E. McKenney wrote:
> The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> that the associated hrtimer has expired.  This means that the hrtimer
> handler can be storing to this field while other code is loading from it
> to check for expiry.  Note that additional races appear for hrtimers that
> can be restarted, which could be argued to be a user error.  However, that
> is no reason to let the compiler introduce additional confusion, and to
> this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> 
> Therefore, apply this accessor to kernel/futex/waitwake.c.
> 
> KCSAN located this issue.
> 
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

Reviewed-by: Dmitry Ilvokhin <d@ilvokhin.com>

[PATCH RFC 6/9] timers: Use accessor for hrtimer_sleeper ->task field in sleep_timeout.c

[Paul E. McKenney]

The hrtimer_sleeper structure's ->task field is used as a flag to indicate
that the associated hrtimer has expired.  This means that the hrtimer
handler can be storing to this field while other code is loading from it
to check for expiry.  Note that additional races appear for hrtimers that
can be restarted, which could be argued to be a user error.  However, that
is no reason to let the compiler introduce additional confusion, and to
this end, the hrtimer_sleeper_task_get() was introduced, use of which also
has the benefit of avoiding open-code access to hrtimer_sleeper innards.

Therefore, apply this accessor to schedule_hrtimeout_range_clock().

KCSAN located this issue.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
---
 kernel/time/sleep_timeout.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/sleep_timeout.c b/kernel/time/sleep_timeout.c
index 3c90574bd904f1..ad8c415851ae19 100644
--- a/kernel/time/sleep_timeout.c
+++ b/kernel/time/sleep_timeout.c
@@ -212,7 +212,7 @@ int __sched schedule_hrtimeout_range_clock(ktime_t *expires, u64 delta,
 	hrtimer_set_expires_range_ns(&t.timer, *expires, delta);
 	hrtimer_sleeper_start_expires(&t, mode);
 
-	if (likely(t.task))
+	if (likely(hrtimer_sleeper_task_get(&t)))
 		schedule();
 
 	hrtimer_cancel(&t.timer);
@@ -220,7 +220,7 @@ int __sched schedule_hrtimeout_range_clock(ktime_t *expires, u64 delta,
 
 	__set_current_state(TASK_RUNNING);
 
-	return !t.task ? 0 : -EINTR;
+	return !hrtimer_sleeper_task_get(&t) ? 0 : -EINTR;
 }
 EXPORT_SYMBOL_GPL(schedule_hrtimeout_range_clock);
 
-- 
2.40.1

Re: [PATCH RFC 6/9] timers: Use accessor for hrtimer_sleeper ->task field in sleep_timeout.c

[Dmitry Ilvokhin]

On Thu, Jul 30, 2026 at 05:40:16PM -0700, Paul E. McKenney wrote:
> The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> that the associated hrtimer has expired.  This means that the hrtimer
> handler can be storing to this field while other code is loading from it
> to check for expiry.  Note that additional races appear for hrtimers that
> can be restarted, which could be argued to be a user error.  However, that
> is no reason to let the compiler introduce additional confusion, and to
> this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> 
> Therefore, apply this accessor to schedule_hrtimeout_range_clock().
> 
> KCSAN located this issue.
> 
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

Reviewed-by: Dmitry Ilvokhin <d@ilvokhin.com>

[PATCH RFC 7/9] net: pktgen: Use accessor for hrtimer_sleeper ->task field

[Paul E. McKenney]

The hrtimer_sleeper structure's ->task field is used as a flag to indicate
that the associated hrtimer has expired.  This means that the hrtimer
handler can be storing to this field while other code is loading from it
to check for expiry.  Note that additional races appear for hrtimers that
can be restarted, which could be argued to be a user error.  However, that
is no reason to let the compiler introduce additional confusion, and to
this end, the hrtimer_sleeper_task_get() was introduced, use of which also
has the benefit of avoiding open-code access to hrtimer_sleeper innards.

Therefore, apply this accessor to the pktgen spin() function.

KCSAN located this issue.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: <netdev@vger.kernel.org>
---
 net/core/pktgen.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 8e185b31828853..f4a6be18267ddb 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2345,11 +2345,11 @@ static void spin(struct pktgen_dev *pkt_dev, ktime_t spin_until)
 			set_current_state(TASK_INTERRUPTIBLE);
 			hrtimer_sleeper_start_expires(&t, HRTIMER_MODE_ABS);
 
-			if (likely(t.task))
+			if (likely(hrtimer_sleeper_task_get(&t)))
 				schedule();
 
 			hrtimer_cancel(&t.timer);
-		} while (t.task && pkt_dev->running && !signal_pending(current));
+		} while (hrtimer_sleeper_task_get(&t) && pkt_dev->running && !signal_pending(current));
 		__set_current_state(TASK_RUNNING);
 		end_time = ktime_get();
 	}
-- 
2.40.1

[PATCH RFC 8/9] rtmutex: Use accessor for hrtimer_sleeper ->task field

[Paul E. McKenney]

The hrtimer_sleeper structure's ->task field is used as a flag to indicate
that the associated hrtimer has expired.  This means that the hrtimer
handler can be storing to this field while other code is loading from it
to check for expiry.  Note that additional races appear for hrtimers that
can be restarted, which could be argued to be a user error.  However, that
is no reason to let the compiler introduce additional confusion, and to
this end, the hrtimer_sleeper_task_get() was introduced, use of which also
has the benefit of avoiding open-code access to hrtimer_sleeper innards.

Therefore, apply this accessor to rt_mutex_slowlock_block().

KCSAN located this issue.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Boqun Feng <boqun@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
---
 kernel/locking/rtmutex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 4728631ae71940..5a9534c715b845 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1644,7 +1644,7 @@ static int __sched rt_mutex_slowlock_block(struct rt_mutex_base *lock,
 			break;
 		}
 
-		if (timeout && !timeout->task) {
+		if (timeout && !hrtimer_sleeper_task_get(timeout)) {
 			ret = -ETIMEDOUT;
 			break;
 		}
-- 
2.40.1

Re: [PATCH RFC 8/9] rtmutex: Use accessor for hrtimer_sleeper ->task field

[Dmitry Ilvokhin]

On Thu, Jul 30, 2026 at 05:40:18PM -0700, Paul E. McKenney wrote:
> The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> that the associated hrtimer has expired.  This means that the hrtimer
> handler can be storing to this field while other code is loading from it
> to check for expiry.  Note that additional races appear for hrtimers that
> can be restarted, which could be argued to be a user error.  However, that
> is no reason to let the compiler introduce additional confusion, and to
> this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> 
> Therefore, apply this accessor to rt_mutex_slowlock_block().
> 
> KCSAN located this issue.
> 
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

Reviewed-by: Dmitry Ilvokhin <d@ilvokhin.com>

Re: [PATCH RFC 8/9] rtmutex: Use accessor for hrtimer_sleeper ->task field

[Paul E. McKenney]

On Tue, Aug 04, 2026 at 05:32:31PM +0000, Dmitry Ilvokhin wrote:
> On Thu, Jul 30, 2026 at 05:40:18PM -0700, Paul E. McKenney wrote:
> > The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> > that the associated hrtimer has expired.  This means that the hrtimer
> > handler can be storing to this field while other code is loading from it
> > to check for expiry.  Note that additional races appear for hrtimers that
> > can be restarted, which could be argued to be a user error.  However, that
> > is no reason to let the compiler introduce additional confusion, and to
> > this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> > has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> > 
> > Therefore, apply this accessor to rt_mutex_slowlock_block().
> > 
> > KCSAN located this issue.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> 
> Reviewed-by: Dmitry Ilvokhin <d@ilvokhin.com>

I will apply these on my next rebase, thank you!

							Thanx, Paul

[PATCH RFC 9/9] futex: Use accessor for hrtimer_sleeper ->task field in requeue

[Paul E. McKenney]

The hrtimer_sleeper structure's ->task field is used as a flag to indicate
that the associated hrtimer has expired.  This means that the hrtimer
handler can be storing to this field while other code is loading from it
to check for expiry.  Note that additional races appear for hrtimers that
can be restarted, which could be argued to be a user error.  However, that
is no reason to let the compiler introduce additional confusion, and to
this end, the hrtimer_sleeper_task_get() was introduced, use of which also
has the benefit of avoiding open-code access to hrtimer_sleeper innards.

Therefore, apply this accessor to handle_early_requeue_pi_wakeup().

KCSAN located this issue.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: "André Almeida" <andrealmeid@igalia.com>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
---
 kernel/futex/requeue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/futex/requeue.c b/kernel/futex/requeue.c
index 79823ad136830a..196d6ff148a4d8 100644
--- a/kernel/futex/requeue.c
+++ b/kernel/futex/requeue.c
@@ -736,7 +736,7 @@ int handle_early_requeue_pi_wakeup(struct futex_hash_bucket *hb,
 
 	/* Handle spurious wakeups gracefully */
 	ret = -EWOULDBLOCK;
-	if (timeout && !timeout->task)
+	if (timeout && !hrtimer_sleeper_task_get(timeout))
 		ret = -ETIMEDOUT;
 	else if (signal_pending(current))
 		ret = -ERESTARTNOINTR;
-- 
2.40.1

Re: [PATCH RFC 9/9] futex: Use accessor for hrtimer_sleeper ->task field in requeue

[André Almeida]

Em 30/07/2026 21:40, Paul E. McKenney escreveu:
> The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> that the associated hrtimer has expired.  This means that the hrtimer
> handler can be storing to this field while other code is loading from it
> to check for expiry.  Note that additional races appear for hrtimers that
> can be restarted, which could be argued to be a user error.  However, that
> is no reason to let the compiler introduce additional confusion, and to
> this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> 
> Therefore, apply this accessor to handle_early_requeue_pi_wakeup().
> 
> KCSAN located this issue.
> 
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Darren Hart <dvhart@infradead.org>
> Cc: Davidlohr Bueso <dave@stgolabs.net>
> Cc: "André Almeida" <andrealmeid@igalia.com>
> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: André Almeida <andrealmeid@igalia.com>

Re: [PATCH RFC 9/9] futex: Use accessor for hrtimer_sleeper ->task field in requeue

[Paul E. McKenney]

On Mon, Aug 03, 2026 at 12:21:23PM -0300, André Almeida wrote:
> Em 30/07/2026 21:40, Paul E. McKenney escreveu:
> > The hrtimer_sleeper structure's ->task field is used as a flag to indicate
> > that the associated hrtimer has expired.  This means that the hrtimer
> > handler can be storing to this field while other code is loading from it
> > to check for expiry.  Note that additional races appear for hrtimers that
> > can be restarted, which could be argued to be a user error.  However, that
> > is no reason to let the compiler introduce additional confusion, and to
> > this end, the hrtimer_sleeper_task_get() was introduced, use of which also
> > has the benefit of avoiding open-code access to hrtimer_sleeper innards.
> > 
> > Therefore, apply this accessor to handle_early_requeue_pi_wakeup().
> > 
> > KCSAN located this issue.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Darren Hart <dvhart@infradead.org>
> > Cc: Davidlohr Bueso <dave@stgolabs.net>
> > Cc: "André Almeida" <andrealmeid@igalia.com>
> > Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
> > Cc: Frederic Weisbecker <frederic@kernel.org>
> > Cc: Thomas Gleixner <tglx@kernel.org>
> Reviewed-by: André Almeida <andrealmeid@igalia.com>

Thank you!  I will apply both on my next rebase.

							Thanx, Paul