Re: [PATCH 02/10] sched_ext: Block proxy donors across scheduler transitions

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] sched_ext activation and PI de-boosting bypass scx_prepare_setscheduler(), leaking retained proxy donors into the BPF scheduler.
--

--- Patch [2]: [PATCH 02/10] sched_ext: Block proxy donors across scheduler transitions ---
commit 824f6d5806618a51db9777883b9153164c747f32
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: Block proxy donors across scheduler transitions

This patch makes sched_ext reject retained proxy donors by default. It forces
blocked tasks through the regular block path in schedule() and fully
deactivates a retained donor before sched_setscheduler() moves it into the
EXT class.

[ ... ]

> diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
> index b215b0ead9a60..2bbba3dc8c890 100644
> --- a/kernel/sched/syscalls.c
> +++ b/kernel/sched/syscalls.c
> @@ -678,6 +678,9 @@ int __sched_setscheduler(struct task_struct *p,
>  	if (prev_class != next_class)
>  		queue_flags |= DEQUEUE_CLASS;
>  
> +	if (!(attr->sched_flags & SCHED_FLAG_KEEP_PARAMS))
> +		scx_prepare_setscheduler(p, next_class);
> +

[Severity: High]
Can retained proxy donors leak into the ext_sched_class without the BPF
scheduler opting in during global activation or PI de-boosting?

Looking at scx_root_enable_workfn() in kernel/sched/ext/ext.c, tasks
transition to ext_sched_class without invoking scx_prepare_setscheduler():

kernel/sched/ext/ext.c:scx_root_enable_workfn() {
...
		if (old_class != new_class)
			queue_flags |= DEQUEUE_CLASS;

		scoped_guard (sched_change, p, queue_flags) {
			p->scx.slice = READ_ONCE(sch->slice_dfl);
			p->sched_class = new_class;
		}
...
}

A similar transition occurs during PI de-boosting:

kernel/sched/core.c:rt_mutex_setprio() {
...
	prev_class = p->sched_class;
	next_class = __setscheduler_class(p->policy, prio);

	if (prev_class != next_class)
		queue_flag |= DEQUEUE_CLASS;

	scoped_guard (sched_change, p, queue_flag) {
...
}

If a task is blocked on a mutex and retained as a proxy donor, would missing
this check cause the task to bypass the blocking logic? Could this cause
runqueue corruption when the BPF scheduler receives a blocked task it assumes
is runnable?

>  	scoped_guard (sched_change, p, queue_flags) {
>  
>  		if (!(attr->sched_flags & SCHED_FLAG_KEEP_PARAMS)) {

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