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

[sashiko-bot@kernel.org]

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