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

[sashiko-bot@kernel.org]

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?

>  
>  		scoped_guard (sched_change, p, new_class, queue_flags) {
>  			scx_set_task_slice(p, READ_ONCE(sch->slice_dfl));

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