Re: [PATCH 04/14] sched: Add prepare_switch() class callback

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `prepare_switch()` callback is invoked on the incoming `next_class`, but the task may never actually transition to that class if `SCHED_FLAG_KEEP_PARAMS` is set, leaving the prepared state orphaned and leaking resources.
--

--- Patch [4]: [PATCH 04/14] sched: Add prepare_switch() class callback ---
commit f8056ba7bb47e84cdf2c8a5193c3485b3b2d44d0
Author: Andrea Righi <arighi@nvidia.com>

sched: Add prepare_switch() class callback

This commit introduces a prepare_switch() callback for scheduling classes.
It allows an incoming class to prepare a task while the state is still
live, before the normal dequeue and class transition take place.

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 37c87783439f5..66e9ba50f5639 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
[ ... ]
> @@ -11221,7 +11221,9 @@ static inline void sched_mm_cid_fork(struct task_struct *t) { }
>  
>  static DEFINE_PER_CPU(struct sched_change_ctx, sched_change_ctx);
>  
> -struct sched_change_ctx *sched_change_begin(struct task_struct *p, unsigned int flags)
> +struct sched_change_ctx *
> +sched_change_begin(struct task_struct *p, const struct sched_class *next_class,
> +		   unsigned int flags)
>  {
>  	struct sched_change_ctx *ctx = this_cpu_ptr(&sched_change_ctx);
>  	struct rq *rq = task_rq(p);
> @@ -11239,6 +11241,10 @@ struct sched_change_ctx *sched_change_begin(struct task_struct *p, unsigned int
>  		flags |= DEQUEUE_NOCLOCK;
>  	}
>  
> +	if ((flags & DEQUEUE_CLASS) && next_class != p->sched_class &&
> +	    next_class->prepare_switch)
> +		next_class->prepare_switch(rq, p);
> +
>  	if ((flags & DEQUEUE_CLASS) && p->sched_class->switching_from)
>  		p->sched_class->switching_from(rq, p);
>  
[ ... ]
> diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
> index b215b0ead9a60..bc32ce76ff4fe 100644
> --- a/kernel/sched/syscalls.c
> +++ b/kernel/sched/syscalls.c
[ ... ]
> @@ -678,7 +678,7 @@ int __sched_setscheduler(struct task_struct *p,
>  	if (prev_class != next_class)
>  		queue_flags |= DEQUEUE_CLASS;
>  
> -	scoped_guard (sched_change, p, queue_flags) {
> +	scoped_guard (sched_change, p, next_class, queue_flags) {
>  
>  		if (!(attr->sched_flags & SCHED_FLAG_KEEP_PARAMS)) {
>  			__setscheduler_params(p, attr);

[Severity: Medium]
Will this leak resources if a user calls sched_setattr() with a new policy and
sets attr.sched_flags = SCHED_FLAG_KEEP_PARAMS?

In __sched_setscheduler(), if SCHED_FLAG_KEEP_PARAMS is set, the class
assignment p->sched_class = next_class is explicitly skipped.

However, because queue_flags includes DEQUEUE_CLASS, the newly modified
sched_change_begin() unconditionally invokes next_class->prepare_switch(rq, p)
for the incoming class.

Because the task never actually transitions to next_class, does this leave
the prepared state dangling and resources leaked since there won't be a
matching cleanup or transition?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260725160513.57477-1-arighi@nvidia.com?part=4