Re: [PATCH 15/18] sched_ext: Delegate proxy donor admission to BPF schedulers

[Andrea Righi <arighi@nvidia.com>]

On Mon, Aug 31, 2026 at 06:08:37PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The new BPF scheduler receives `ops.dequeue` before `ops.enable` or `ops.enqueue` for retained proxy donors during root scheduler enablement, violating the BPF lifecycle contract.
> --
> 
> commit 2446f36cb7fab90783875259131bf6b0d4fa2d3d
> Author: Andrea Righi <arighi@nvidia.com>
> 
>     sched_ext: Delegate proxy donor admission to BPF schedulers
> 
>     Proxy execution keeps a mutex-blocked donor runnable so that its
>     scheduling context can execute the mutex owner. This patch introduces
>     SCX_OPS_ENQ_BLOCKED to allow schedulers to continue owning blocked donors.
>     A proxy-migrated donor returns through the full wakeup activation path
>     when the mutex is released.
> 
> > diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> > index f23e9f1ee2f3c..06067fe504a24 100644
> > --- a/kernel/sched/ext/ext.c
> > +++ b/kernel/sched/ext/ext.c
> 
> [ ... ]
> 
> > @@ -8027,6 +8108,14 @@ static void scx_root_enable_workfn(struct kthread_work *work)
> >  
> >  		if (old_class != new_class)
> >  			queue_flags |= DEQUEUE_CLASS;
> > +		if (old_class == new_class && new_class == &ext_sched_class) {
> > +			/*
> > +			 * This is an EXT-to-EXT scheduler ownership change, so
> > +			 * sched_change_begin() won't end retained proxy execution.
> > +			 */
> > +			scx_prepare_task_sched_change(p);
> > +			queue_flags |= DEQUEUE_NOCLOCK;
> > +		}
>                  ^
> 
> [Severity: High]
> Does this code call ops.dequeue() on the new BPF scheduler before ops.enable()
> has been called?
> 
> Looking at scx_root_enable_workfn() in kernel/sched/ext/ext.c, the task's
> p->scx.sched is updated to the new scheduler in a previous loop. 
> 
> When scx_prepare_task_sched_change(p) is called during an EXT-to-EXT
> scheduler ownership change, it triggers the following sequence:
> 
> scx_prepare_task_sched_change()
>   sched_proxy_block_task()
>     dequeue_task_scx()
>       ops.dequeue()
> 
> Because dequeue_task_scx() sees the SCX_TASK_IN_CUSTODY flag left over from
> the old scheduler, it executes ops.dequeue() on the new scheduler.
> 
> Since DEQUEUE_CLASS is omitted from queue_flags for EXT-to-EXT transitions,
> the switching_to hook is skipped and scx_enable_task() is never called to
> initialize the per-task state for the new scheduler.
> 
> Can this lead to the BPF program experiencing out-of-bounds map accesses or
> NULL pointer dereferences, as it relies on ops.enable() to initialize state
> before ops.dequeue() is called?

I think the described sequence can't occur during root scheduler enable:
sched_ext is globally disabled while tasks are initialized, so tasks always
enter this path from SCX_TASK_NONE without custody from previous BPF scheduler.

And I think the EXT-to-EXT scenario is unreachable. Here's why: after
__scx_enabled is set, a concurrent transition to EXT goes through
switching_to_scx(), which calls scx_enable_task() and changes the task from
SCX_TASK_READY to SCX_TASK_ENABLED. The second loop consequently skips that
task. Otherwise, a task being moved to EXT still has its old non-EXT class, so
DEQUEUE_CLASS handles the retained proxy state before switching_to_scx() enables
it.

Therefore a SCX_TASK_READY task can't legitimately reach the
old_class == new_class == &ext_sched_class case with SCX_TASK_IN_CUSTODY and
ops.dequeue() can't be called on the new scheduler before ops.enable().

So the EXT-to-EXT special case in the root-enable loop can be removed.

-Andrea