[PATCHSET v2] sched/psi: Fix psimon fork deadlock and rtpoll_timer UAF

[PATCHSET v2] sched/psi: Fix psimon fork deadlock and rtpoll_timer UAF

[Tejun Heo]

Hello,

v2: - Retagged sched/psi (was cgroup) (patch 1).
    - Added a fix for a pre-existing rtpoll_timer use-after-free that the
      Sashiko AI review flagged on the previous posting (patch 2).

v1: https://lore.kernel.org/r/20260710134945-psimon-fix-tj@kernel.org

a5b98009f16d ("sched/psi: fix race between file release and pressure
write") made pressure_write() fork the psimon kthread while holding
cgroup_mutex, which deadlocks against the sched_ext enable path blocking
forks before grabbing cgroup_mutex. Patch 1 moves the fork outside
cgroup_mutex. Patch 2 fixes the use-after-free from a schedule attempt
re-arming group->rtpoll_timer behind psi_trigger_destroy() by shutting
down the timer when the group is freed.

Matt, patch 1 is unchanged from the previous posting except for the
subject prefix, so test results against that posting still apply.

Peter, once these are reviewed and tested, how do you want them routed?
I can take them through the cgroup tree if that works for you.

Patches:

  [PATCH 1/2] sched/psi: Create the psimon kthread outside of cgroup_mutex
  [PATCH 2/2] sched/psi: Shut down rtpoll_timer in psi_cgroup_free()

Based on cgroup/for-7.2-fixes (97fef6025844).

 include/linux/psi.h    |  4 ++-
 kernel/cgroup/cgroup.c | 23 +++++++++++++++-
 kernel/sched/psi.c     | 75 +++++++++++++++++++++++++++++++++++++++-----------
 3 files changed, 84 insertions(+), 18 deletions(-)

Thanks.

--
tejun

[PATCH 1/2] sched/psi: Create the psimon kthread outside of cgroup_mutex

[Tejun Heo]

a5b98009f16d ("sched/psi: fix race between file release and pressure write")
made pressure_write() hold cgroup_mutex across psi_trigger_create(), which
forks the psimon kthread for the first rtpoll trigger. As kthread creation
depends on the whole fork path, the commit inadvertently created a lot of
unwanted locking dependencies from cgroup_mutex.

sched_ext got hit by one: its enable path blocks forks and then grabs
cgroup_mutex, so a pressure write racing a scheduler enable deadlocks, with
every other fork piling up behind.

Fix it by splitting trigger creation so that the worker is forked with
cgroup_mutex dropped and the kernfs active reference left broken. The latter
matters because rmdir and cgroup.pressure writes drain active references
under cgroup_mutex. Publishing the trigger last keeps error reporting
synchronous and preserves the of->priv lifetime rules.

The trigger registered in the first stage pins the group's rtpoll machinery
across the unlocked window, leaving only creation races to resolve. The
catch-up poll on installation covers scheduling attempts dropped while there
was no worker.

v2: Retagged sched/psi (was cgroup).

Fixes: a5b98009f16d ("sched/psi: fix race between file release and pressure write")
Cc: stable@vger.kernel.org
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Edward Adam Davis <eadavis@qq.com>
Cc: Chen Ridong <chenridong@huaweicloud.com>
Reported-by: Matt Fleming <mfleming@cloudflare.com>
Closes: https://lore.kernel.org/all/20260710100441.2653477-1-matt@readmodwrite.com/
Signed-off-by: Tejun Heo <tj@kernel.org>
---
 include/linux/psi.h    |  4 ++-
 kernel/cgroup/cgroup.c | 23 +++++++++++++-
 kernel/sched/psi.c     | 69 ++++++++++++++++++++++++++++++++----------
 3 files changed, 78 insertions(+), 18 deletions(-)

diff --git a/include/linux/psi.h b/include/linux/psi.h
index e0745873e3f2..7966e3ac03b9 100644
--- a/include/linux/psi.h
+++ b/include/linux/psi.h
@@ -25,7 +25,9 @@ void psi_memstall_leave(unsigned long *flags);
 int psi_show(struct seq_file *s, struct psi_group *group, enum psi_res res);
 struct psi_trigger *psi_trigger_create(struct psi_group *group, char *buf,
 				       enum psi_res res, struct file *file,
-				       struct kernfs_open_file *of);
+				       struct kernfs_open_file *of,
+				       bool *need_rtpoll_worker);
+int psi_trigger_create_rtpoll_worker(struct psi_group *group);
 void psi_trigger_destroy(struct psi_trigger *t);
 
 __poll_t psi_trigger_poll(void **trigger_ptr, struct file *file,
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 38f8d9df8fbc..b5b461d4418b 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -3996,6 +3996,7 @@ static ssize_t pressure_write(struct kernfs_open_file *of, char *buf,
 	struct psi_trigger *new;
 	struct cgroup *cgrp;
 	struct psi_group *psi;
+	bool need_rtpoll_worker;
 	ssize_t ret = 0;
 
 	cgrp = cgroup_kn_lock_live(of->kn, false);
@@ -4015,12 +4016,32 @@ static ssize_t pressure_write(struct kernfs_open_file *of, char *buf,
 	}
 
 	psi = cgroup_psi(cgrp);
-	new = psi_trigger_create(psi, buf, res, of->file, of);
+	new = psi_trigger_create(psi, buf, res, of->file, of,
+				 &need_rtpoll_worker);
 	if (IS_ERR(new)) {
 		ret = PTR_ERR(new);
 		goto out_unlock;
 	}
 
+	/*
+	 * The worker fork must run with neither cgroup_mutex nor the file's
+	 * kernfs active reference held. The latter is broken since
+	 * cgroup_kn_lock_live(). @of->priv may be released while unlocked, so
+	 * recheck before publishing @new.
+	 */
+	if (need_rtpoll_worker) {
+		cgroup_unlock();
+		ret = psi_trigger_create_rtpoll_worker(psi);
+		cgroup_lock();
+
+		if (!ret && !of->priv)
+			ret = -ENODEV;
+		if (ret) {
+			psi_trigger_destroy(new);
+			goto out_unlock;
+		}
+	}
+
 	smp_store_release(&ctx->psi.trigger, new);
 
 out_unlock:
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index d9c9d9480a45..565ec7b80743 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -1292,9 +1292,44 @@ int psi_show(struct seq_file *m, struct psi_group *group, enum psi_res res)
 	return 0;
 }
 
+/*
+ * Create @group's rtpoll worker after psi_trigger_create() reported the need
+ * for one. kthread creation depends on the whole fork path and we don't want
+ * all of that nested inside cgroup_mutex, so the caller must drop it and any
+ * other lock that forks can wait behind. If two callers race, the loser stops
+ * its never-woken kthread.
+ */
+int psi_trigger_create_rtpoll_worker(struct psi_group *group)
+{
+	struct task_struct *task;
+
+	task = kthread_create(psi_rtpoll_worker, group, "psimon");
+	if (IS_ERR(task))
+		return PTR_ERR(task);
+
+	scoped_guard(mutex, &group->rtpoll_trigger_lock) {
+		if (!rcu_access_pointer(group->rtpoll_task)) {
+			atomic_set(&group->rtpoll_wakeup, 0);
+			wake_up_process(task);
+			rcu_assign_pointer(group->rtpoll_task, task);
+
+			/*
+			 * Poll once to catch up on scheduling attempts dropped
+			 * while there was no rtpoll worker.
+			 */
+			psi_schedule_rtpoll_work(group, 1, true);
+			return 0;
+		}
+	}
+
+	kthread_stop(task);
+	return 0;
+}
+
 struct psi_trigger *psi_trigger_create(struct psi_group *group, char *buf,
 				       enum psi_res res, struct file *file,
-				       struct kernfs_open_file *of)
+				       struct kernfs_open_file *of,
+				       bool *need_rtpoll_worker)
 {
 	struct psi_trigger *t;
 	enum psi_states state;
@@ -1302,6 +1337,8 @@ struct psi_trigger *psi_trigger_create(struct psi_group *group, char *buf,
 	bool privileged;
 	u32 window_us;
 
+	*need_rtpoll_worker = false;
+
 	if (static_branch_likely(&psi_disabled))
 		return ERR_PTR(-EOPNOTSUPP);
 
@@ -1362,26 +1399,14 @@ struct psi_trigger *psi_trigger_create(struct psi_group *group, char *buf,
 	if (privileged) {
 		mutex_lock(&group->rtpoll_trigger_lock);
 
-		if (!rcu_access_pointer(group->rtpoll_task)) {
-			struct task_struct *task;
-
-			task = kthread_create(psi_rtpoll_worker, group, "psimon");
-			if (IS_ERR(task)) {
-				kfree(t);
-				mutex_unlock(&group->rtpoll_trigger_lock);
-				return ERR_CAST(task);
-			}
-			atomic_set(&group->rtpoll_wakeup, 0);
-			wake_up_process(task);
-			rcu_assign_pointer(group->rtpoll_task, task);
-		}
-
 		list_add(&t->node, &group->rtpoll_triggers);
 		group->rtpoll_min_period = min(group->rtpoll_min_period,
 			div_u64(t->win.size, UPDATES_PER_WINDOW));
 		group->rtpoll_nr_triggers[t->state]++;
 		group->rtpoll_states |= (1 << t->state);
 
+		*need_rtpoll_worker = !rcu_access_pointer(group->rtpoll_task);
+
 		mutex_unlock(&group->rtpoll_trigger_lock);
 	} else {
 		mutex_lock(&group->avgs_lock);
@@ -1541,6 +1566,8 @@ static ssize_t psi_write(struct file *file, const char __user *user_buf,
 	size_t buf_size;
 	struct seq_file *seq;
 	struct psi_trigger *new;
+	bool need_rtpoll_worker;
+	int ret;
 
 	if (static_branch_likely(&psi_disabled))
 		return -EOPNOTSUPP;
@@ -1565,12 +1592,22 @@ static ssize_t psi_write(struct file *file, const char __user *user_buf,
 		return -EBUSY;
 	}
 
-	new = psi_trigger_create(&psi_system, buf, res, file, NULL);
+	new = psi_trigger_create(&psi_system, buf, res, file, NULL,
+				 &need_rtpoll_worker);
 	if (IS_ERR(new)) {
 		mutex_unlock(&seq->lock);
 		return PTR_ERR(new);
 	}
 
+	if (need_rtpoll_worker) {
+		ret = psi_trigger_create_rtpoll_worker(&psi_system);
+		if (ret) {
+			psi_trigger_destroy(new);
+			mutex_unlock(&seq->lock);
+			return ret;
+		}
+	}
+
 	smp_store_release(&seq->private, new);
 	mutex_unlock(&seq->lock);
 
-- 
2.55.0

Re: [PATCH 1/2] sched/psi: Create the psimon kthread outside of cgroup_mutex

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calling psi_trigger_destroy() while holding cgroup_mutex introduces severe system-wide latency spikes.
--

--- Patch [1]: [PATCH 1/2] sched/psi: Create the psimon kthread outside of cgroup_mutex ---
commit 4990aba341f12c025b0b99ecf8869c68be847294
Author: Tejun Heo <tj@kernel.org>
sched/psi: Create the psimon kthread outside of cgroup_mutex

This commit splits psi trigger creation into two stages to avoid locking
dependencies. It drops cgroup_mutex before forking the psimon kthread, then
reacquires the mutex to verify the cgroup is still alive before publishing
the new trigger.

Closes: https://lore.kernel.org/all/20260710100441.2653477-1-matt@readmodwrite.com/

> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 38f8d9df8fbc4..b5b461d4418b1 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
[ ... ]
> @@ -4015,12 +4016,32 @@ static ssize_t pressure_write(struct kernfs_open_file *of, char *buf,
>  	}
>  
>  	psi = cgroup_psi(cgrp);
> -	new = psi_trigger_create(psi, buf, res, of->file, of);
> +	new = psi_trigger_create(psi, buf, res, of->file, of,
> +				 &need_rtpoll_worker);
>  	if (IS_ERR(new)) {
>  		ret = PTR_ERR(new);
>  		goto out_unlock;
>  	}
>  
> +	/*
> +	 * The worker fork must run with neither cgroup_mutex nor the file's
> +	 * kernfs active reference held. The latter is broken since
> +	 * cgroup_kn_lock_live(). @of->priv may be released while unlocked, so
> +	 * recheck before publishing @new.
> +	 */
> +	if (need_rtpoll_worker) {
> +		cgroup_unlock();
> +		ret = psi_trigger_create_rtpoll_worker(psi);
> +		cgroup_lock();
> +
> +		if (!ret && !of->priv)
> +			ret = -ENODEV;
> +		if (ret) {
> +			psi_trigger_destroy(new);

[Severity: High]
Since psi_trigger_destroy() unconditionally blocks on synchronize_rcu(), will
calling it here while holding cgroup_mutex cause system-wide latency spikes?

Looking at psi_trigger_destroy() in kernel/sched/psi.c, it does:

	/*
	 * Wait for psi_schedule_rtpoll_work RCU to complete its read-side
	 * critical section before destroying the trigger and optionally the
	 * rtpoll_task.
	 */
	synchronize_rcu();

If this error path is reached (e.g. by racing pressure_write() with cgroup
rmdir making of->priv NULL), the calling thread would sleep for an RCU grace
period while holding cgroup_mutex, stalling all other cgroup operations.

Could the trigger destruction be deferred until after cgroup_mutex is dropped,
or handled asynchronously to avoid stalling the cgroup subsystem?

> +			goto out_unlock;
> +		}
> +	}
> +
>  	smp_store_release(&ctx->psi.trigger, new);
>  
>  out_unlock:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260712174619.3553231-1-tj@kernel.org?part=1

Re: [PATCH 1/2] sched/psi: Create the psimon kthread outside of cgroup_mutex

[Tejun Heo]

Hello.

> If this error path is reached (e.g. by racing pressure_write() with cgroup
> rmdir making of->priv NULL), the calling thread would sleep for an RCU grace
> period while holding cgroup_mutex, stalling all other cgroup operations.
>
> Could the trigger destruction be deferred until after cgroup_mutex is dropped,
> or handled asynchronously to avoid stalling the cgroup subsystem?

This is pre-existing - rmdir and cgroup.pressure disable already destroy
triggers under cgroup_mutex when draining open fds. Maybe something to
improve in the future.

Thanks.

--
tejun

Re: [PATCH 1/2] sched/psi: Create the psimon kthread outside of cgroup_mutex

[Johannes Weiner]

On Sun, Jul 12, 2026 at 07:46:18AM -1000, Tejun Heo wrote:
> a5b98009f16d ("sched/psi: fix race between file release and pressure write")
> made pressure_write() hold cgroup_mutex across psi_trigger_create(), which
> forks the psimon kthread for the first rtpoll trigger. As kthread creation
> depends on the whole fork path, the commit inadvertently created a lot of
> unwanted locking dependencies from cgroup_mutex.
> 
> sched_ext got hit by one: its enable path blocks forks and then grabs
> cgroup_mutex, so a pressure write racing a scheduler enable deadlocks, with
> every other fork piling up behind.
> 
> Fix it by splitting trigger creation so that the worker is forked with
> cgroup_mutex dropped and the kernfs active reference left broken. The latter
> matters because rmdir and cgroup.pressure writes drain active references
> under cgroup_mutex. Publishing the trigger last keeps error reporting
> synchronous and preserves the of->priv lifetime rules.
> 
> The trigger registered in the first stage pins the group's rtpoll machinery
> across the unlocked window, leaving only creation races to resolve. The
> catch-up poll on installation covers scheduling attempts dropped while there
> was no worker.
> 
> v2: Retagged sched/psi (was cgroup).
> 
> Fixes: a5b98009f16d ("sched/psi: fix race between file release and pressure write")
> Cc: stable@vger.kernel.org
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Edward Adam Davis <eadavis@qq.com>
> Cc: Chen Ridong <chenridong@huaweicloud.com>
> Reported-by: Matt Fleming <mfleming@cloudflare.com>
> Closes: https://lore.kernel.org/all/20260710100441.2653477-1-matt@readmodwrite.com/
> Signed-off-by: Tejun Heo <tj@kernel.org>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

Re: [PATCH 1/2] sched/psi: Create the psimon kthread outside of cgroup_mutex

[Matt Fleming]

On Sun, Jul 12, 2026 at 07:46:18AM -1000, Tejun Heo wrote:
> a5b98009f16d ("sched/psi: fix race between file release and pressure write")
> made pressure_write() hold cgroup_mutex across psi_trigger_create(), which
> forks the psimon kthread for the first rtpoll trigger. As kthread creation
> depends on the whole fork path, the commit inadvertently created a lot of
> unwanted locking dependencies from cgroup_mutex.
> 
> sched_ext got hit by one: its enable path blocks forks and then grabs
> cgroup_mutex, so a pressure write racing a scheduler enable deadlocks, with
> every other fork piling up behind.
> 
> Fix it by splitting trigger creation so that the worker is forked with
> cgroup_mutex dropped and the kernfs active reference left broken. The latter
> matters because rmdir and cgroup.pressure writes drain active references
> under cgroup_mutex. Publishing the trigger last keeps error reporting
> synchronous and preserves the of->priv lifetime rules.
> 
> The trigger registered in the first stage pins the group's rtpoll machinery
> across the unlocked window, leaving only creation races to resolve. The
> catch-up poll on installation covers scheduling attempts dropped while there
> was no worker.
> 
> v2: Retagged sched/psi (was cgroup).
> 
> Fixes: a5b98009f16d ("sched/psi: fix race between file release and pressure write")
> Cc: stable@vger.kernel.org
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Edward Adam Davis <eadavis@qq.com>
> Cc: Chen Ridong <chenridong@huaweicloud.com>
> Reported-by: Matt Fleming <mfleming@cloudflare.com>
> Closes: https://lore.kernel.org/all/20260710100441.2653477-1-matt@readmodwrite.com/
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
>  include/linux/psi.h    |  4 ++-
>  kernel/cgroup/cgroup.c | 23 +++++++++++++-
>  kernel/sched/psi.c     | 69 ++++++++++++++++++++++++++++++++----------
>  3 files changed, 78 insertions(+), 18 deletions(-)

Tested-by: Matt Fleming <mfleming@cloudflare.com>

Re: [PATCH 1/2] sched/psi: Create the psimon kthread outside of cgroup_mutex

[Suren Baghdasaryan]

On Mon, Jul 13, 2026 at 6:48 AM Matt Fleming <matt@readmodwrite.com> wrote:
>
> On Sun, Jul 12, 2026 at 07:46:18AM -1000, Tejun Heo wrote:
> > a5b98009f16d ("sched/psi: fix race between file release and pressure write")
> > made pressure_write() hold cgroup_mutex across psi_trigger_create(), which
> > forks the psimon kthread for the first rtpoll trigger. As kthread creation
> > depends on the whole fork path, the commit inadvertently created a lot of
> > unwanted locking dependencies from cgroup_mutex.
> >
> > sched_ext got hit by one: its enable path blocks forks and then grabs
> > cgroup_mutex, so a pressure write racing a scheduler enable deadlocks, with
> > every other fork piling up behind.
> >
> > Fix it by splitting trigger creation so that the worker is forked with
> > cgroup_mutex dropped and the kernfs active reference left broken. The latter
> > matters because rmdir and cgroup.pressure writes drain active references
> > under cgroup_mutex. Publishing the trigger last keeps error reporting
> > synchronous and preserves the of->priv lifetime rules.
> >
> > The trigger registered in the first stage pins the group's rtpoll machinery
> > across the unlocked window, leaving only creation races to resolve. The
> > catch-up poll on installation covers scheduling attempts dropped while there
> > was no worker.
> >
> > v2: Retagged sched/psi (was cgroup).
> >
> > Fixes: a5b98009f16d ("sched/psi: fix race between file release and pressure write")
> > Cc: stable@vger.kernel.org
> > Cc: Johannes Weiner <hannes@cmpxchg.org>
> > Cc: Edward Adam Davis <eadavis@qq.com>
> > Cc: Chen Ridong <chenridong@huaweicloud.com>
> > Reported-by: Matt Fleming <mfleming@cloudflare.com>
> > Closes: https://lore.kernel.org/all/20260710100441.2653477-1-matt@readmodwrite.com/
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > ---
> >  include/linux/psi.h    |  4 ++-
> >  kernel/cgroup/cgroup.c | 23 +++++++++++++-
> >  kernel/sched/psi.c     | 69 ++++++++++++++++++++++++++++++++----------
> >  3 files changed, 78 insertions(+), 18 deletions(-)
>
> Tested-by: Matt Fleming <mfleming@cloudflare.com>

Acked-by: Suren Baghdasaryan <surenb@google.com>

[PATCH 2/2] sched/psi: Shut down rtpoll_timer in psi_cgroup_free()

[Tejun Heo]

psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath
and can race psi_trigger_destroy() taking down the last rtpoll trigger under
rtpoll_trigger_lock:

  psi_schedule_rtpoll_work()        psi_trigger_destroy()

  rcu_read_lock();
  task = rcu_dereference(rtpoll_task);
                                    rcu_assign_pointer(rtpoll_task, NULL);
                                    timer_delete(&rtpoll_timer);
  mod_timer(&rtpoll_timer, ...);
  rcu_read_unlock();
                                    synchronize_rcu();
                                    kthread_stop(task_to_destroy);

The group can then be freed with the re-armed timer still pending, and
poll_timer_fn() runs on freed memory.

461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling
mechanism") deleted the timer synchronously after the synchronize_rcu(),
which prevented this but raced trigger creation instead: the deletion could
cancel the timer that a new trigger set armed during the grace period and,
as creation also reinitialized the timer at the time, corrupt it.
8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the
initialization into group_init() and the deletion into the locked section,
trading the creation races for the window above.

Neither placement in the destruction path works. A pending timer firing
while the group is alive is harmless though. poll_timer_fn() just wakes the
rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's
lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it
by then. timer_shutdown_sync() because the timer is never armed again.

Fixes: 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy")
Cc: stable@vger.kernel.org # v5.10+
Reported-by: Sashiko AI <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260711000434.36C4A1F000E9@smtp.kernel.org/
Signed-off-by: Tejun Heo <tj@kernel.org>
---
 kernel/sched/psi.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 565ec7b80743..e2e825dcd088 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -1134,6 +1134,12 @@ void psi_cgroup_free(struct cgroup *cgroup)
 		return;
 
 	cancel_delayed_work_sync(&cgroup->psi->avgs_work);
+	/*
+	 * A psi_schedule_rtpoll_work() call racing the last trigger's
+	 * destruction may have re-armed the timer after psi_trigger_destroy()
+	 * deleted it. Spurious firing while the group is alive is harmless.
+	 */
+	timer_shutdown_sync(&cgroup->psi->rtpoll_timer);
 	free_percpu(cgroup->psi->pcpu);
 	/* All triggers must be removed by now */
 	WARN_ONCE(cgroup->psi->rtpoll_states, "psi: trigger leak\n");
-- 
2.55.0

Re: [PATCH 2/2] sched/psi: Shut down rtpoll_timer in psi_cgroup_free()

[Johannes Weiner]

On Sun, Jul 12, 2026 at 07:46:19AM -1000, Tejun Heo wrote:
> psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath
> and can race psi_trigger_destroy() taking down the last rtpoll trigger under
> rtpoll_trigger_lock:
> 
>   psi_schedule_rtpoll_work()        psi_trigger_destroy()
> 
>   rcu_read_lock();
>   task = rcu_dereference(rtpoll_task);
>                                     rcu_assign_pointer(rtpoll_task, NULL);
>                                     timer_delete(&rtpoll_timer);
>   mod_timer(&rtpoll_timer, ...);
>   rcu_read_unlock();
>                                     synchronize_rcu();
>                                     kthread_stop(task_to_destroy);
> 
> The group can then be freed with the re-armed timer still pending, and
> poll_timer_fn() runs on freed memory.
> 
> 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling
> mechanism") deleted the timer synchronously after the synchronize_rcu(),
> which prevented this but raced trigger creation instead: the deletion could
> cancel the timer that a new trigger set armed during the grace period and,
> as creation also reinitialized the timer at the time, corrupt it.
> 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the
> initialization into group_init() and the deletion into the locked section,
> trading the creation races for the window above.
> 
> Neither placement in the destruction path works. A pending timer firing
> while the group is alive is harmless though. poll_timer_fn() just wakes the
> rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's
> lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it
> by then. timer_shutdown_sync() because the timer is never armed again.
> 
> Fixes: 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy")
> Cc: stable@vger.kernel.org # v5.10+
> Reported-by: Sashiko AI <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/all/20260711000434.36C4A1F000E9@smtp.kernel.org/
> Signed-off-by: Tejun Heo <tj@kernel.org>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

Both these patches look good to me, but Suren can you please also take
a look?

Re: [PATCH 2/2] sched/psi: Shut down rtpoll_timer in psi_cgroup_free()

[Suren Baghdasaryan]

On Mon, Jul 13, 2026 at 3:56 AM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Sun, Jul 12, 2026 at 07:46:19AM -1000, Tejun Heo wrote:
> > psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath
> > and can race psi_trigger_destroy() taking down the last rtpoll trigger under
> > rtpoll_trigger_lock:
> >
> >   psi_schedule_rtpoll_work()        psi_trigger_destroy()
> >
> >   rcu_read_lock();
> >   task = rcu_dereference(rtpoll_task);
> >                                     rcu_assign_pointer(rtpoll_task, NULL);
> >                                     timer_delete(&rtpoll_timer);
> >   mod_timer(&rtpoll_timer, ...);
> >   rcu_read_unlock();
> >                                     synchronize_rcu();
> >                                     kthread_stop(task_to_destroy);
> >
> > The group can then be freed with the re-armed timer still pending, and
> > poll_timer_fn() runs on freed memory.
> >
> > 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling
> > mechanism") deleted the timer synchronously after the synchronize_rcu(),
> > which prevented this but raced trigger creation instead: the deletion could
> > cancel the timer that a new trigger set armed during the grace period and,
> > as creation also reinitialized the timer at the time, corrupt it.
> > 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the
> > initialization into group_init() and the deletion into the locked section,
> > trading the creation races for the window above.
> >
> > Neither placement in the destruction path works. A pending timer firing
> > while the group is alive is harmless though. poll_timer_fn() just wakes the
> > rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's
> > lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it
> > by then. timer_shutdown_sync() because the timer is never armed again.
> >
> > Fixes: 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy")
> > Cc: stable@vger.kernel.org # v5.10+
> > Reported-by: Sashiko AI <sashiko-bot@kernel.org>
> > Closes: https://lore.kernel.org/all/20260711000434.36C4A1F000E9@smtp.kernel.org/
> > Signed-off-by: Tejun Heo <tj@kernel.org>
>
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
>
> Both these patches look good to me, but Suren can you please also take
> a look?

Yes, I'm on it. Need some time to remind myself of all the details of
the implementation.

Re: [PATCH 2/2] sched/psi: Shut down rtpoll_timer in psi_cgroup_free()

[Suren Baghdasaryan]

On Mon, Jul 13, 2026 at 7:07 AM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Mon, Jul 13, 2026 at 3:56 AM Johannes Weiner <hannes@cmpxchg.org> wrote:
> >
> > On Sun, Jul 12, 2026 at 07:46:19AM -1000, Tejun Heo wrote:
> > > psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath
> > > and can race psi_trigger_destroy() taking down the last rtpoll trigger under
> > > rtpoll_trigger_lock:
> > >
> > >   psi_schedule_rtpoll_work()        psi_trigger_destroy()
> > >
> > >   rcu_read_lock();
> > >   task = rcu_dereference(rtpoll_task);
> > >                                     rcu_assign_pointer(rtpoll_task, NULL);
> > >                                     timer_delete(&rtpoll_timer);
> > >   mod_timer(&rtpoll_timer, ...);
> > >   rcu_read_unlock();
> > >                                     synchronize_rcu();
> > >                                     kthread_stop(task_to_destroy);
> > >
> > > The group can then be freed with the re-armed timer still pending, and
> > > poll_timer_fn() runs on freed memory.
> > >
> > > 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling
> > > mechanism") deleted the timer synchronously after the synchronize_rcu(),
> > > which prevented this but raced trigger creation instead: the deletion could
> > > cancel the timer that a new trigger set armed during the grace period and,
> > > as creation also reinitialized the timer at the time, corrupt it.
> > > 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the
> > > initialization into group_init() and the deletion into the locked section,
> > > trading the creation races for the window above.
> > >
> > > Neither placement in the destruction path works. A pending timer firing
> > > while the group is alive is harmless though. poll_timer_fn() just wakes the
> > > rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's
> > > lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it
> > > by then. timer_shutdown_sync() because the timer is never armed again.
> > >
> > > Fixes: 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy")
> > > Cc: stable@vger.kernel.org # v5.10+
> > > Reported-by: Sashiko AI <sashiko-bot@kernel.org>
> > > Closes: https://lore.kernel.org/all/20260711000434.36C4A1F000E9@smtp.kernel.org/
> > > Signed-off-by: Tejun Heo <tj@kernel.org>
> >
> > Acked-by: Johannes Weiner <hannes@cmpxchg.org>

Acked-by: Suren Baghdasaryan <surenb@google.com>


> >
> > Both these patches look good to me, but Suren can you please also take
> > a look?
>
> Yes, I'm on it. Need some time to remind myself of all the details of
> the implementation.

Re: [PATCH 2/2] sched/psi: Shut down rtpoll_timer in psi_cgroup_free()

[Matt Fleming]

On Sun, Jul 12, 2026 at 07:46:19AM -1000, Tejun Heo wrote:
> psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath
> and can race psi_trigger_destroy() taking down the last rtpoll trigger under
> rtpoll_trigger_lock:
> 
>   psi_schedule_rtpoll_work()        psi_trigger_destroy()
> 
>   rcu_read_lock();
>   task = rcu_dereference(rtpoll_task);
>                                     rcu_assign_pointer(rtpoll_task, NULL);
>                                     timer_delete(&rtpoll_timer);
>   mod_timer(&rtpoll_timer, ...);
>   rcu_read_unlock();
>                                     synchronize_rcu();
>                                     kthread_stop(task_to_destroy);
> 
> The group can then be freed with the re-armed timer still pending, and
> poll_timer_fn() runs on freed memory.
> 
> 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling
> mechanism") deleted the timer synchronously after the synchronize_rcu(),
> which prevented this but raced trigger creation instead: the deletion could
> cancel the timer that a new trigger set armed during the grace period and,
> as creation also reinitialized the timer at the time, corrupt it.
> 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the
> initialization into group_init() and the deletion into the locked section,
> trading the creation races for the window above.
> 
> Neither placement in the destruction path works. A pending timer firing
> while the group is alive is harmless though. poll_timer_fn() just wakes the
> rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's
> lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it
> by then. timer_shutdown_sync() because the timer is never armed again.
> 
> Fixes: 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy")
> Cc: stable@vger.kernel.org # v5.10+
> Reported-by: Sashiko AI <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/all/20260711000434.36C4A1F000E9@smtp.kernel.org/
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
>  kernel/sched/psi.c | 6 ++++++
>  1 file changed, 6 insertions(+)
 
Tested-by: Matt Fleming <mfleming@cloudflare.com>

Re: [PATCHSET v2] sched/psi: Fix psimon fork deadlock and rtpoll_timer UAF

[Matt Fleming]

On Sun, Jul 12, 2026 at 07:46:17AM -1000, Tejun Heo wrote:
> Hello,
> 
> v2: - Retagged sched/psi (was cgroup) (patch 1).
>     - Added a fix for a pre-existing rtpoll_timer use-after-free that the
>       Sashiko AI review flagged on the previous posting (patch 2).
> 
> v1: https://lore.kernel.org/r/20260710134945-psimon-fix-tj@kernel.org
> 
> a5b98009f16d ("sched/psi: fix race between file release and pressure
> write") made pressure_write() fork the psimon kthread while holding
> cgroup_mutex, which deadlocks against the sched_ext enable path blocking
> forks before grabbing cgroup_mutex. Patch 1 moves the fork outside
> cgroup_mutex. Patch 2 fixes the use-after-free from a schedule attempt
> re-arming group->rtpoll_timer behind psi_trigger_destroy() by shutting
> down the timer when the group is freed.
> 
> Matt, patch 1 is unchanged from the previous posting except for the
> subject prefix, so test results against that posting still apply.

I ended up testing both patches. This resolves the issue for me!

Thanks,
Matt