Re: [PATCH 02/10] sched_ext: Block proxy donors across scheduler transitions
[email protected] Mon, 13 Jul 2026 16:41:31 +0000
| Newsgroups | dev.linux.lists.sched-ext |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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/[email protected]?part=2