Re: [PATCH v2] sched_ext: Fix NULL sched deref in kfunc sub-sched error paths

[Tejun Heo]

Hello,

On Thu, Sep 03, 2026 at 01:07:51AM +0800, Wanwu Li wrote:
> Neither wrapper requires a contrived @p. Tasks that are never enabled --
> kthreads and tasks of other classes under SCX_SWITCH_ALL=n -- keep
> p->scx.sched NULL indefinitely; and a task handed over from

This isn't accurate. p->scx.sched is set for every non-idle task on root
enable and on fork regardless of sched class. The only tasks with NULL
p->scx.sched are the ones past sched_ext_dead() and the idle tasks. The new
comments repeat the same claim with "managed by another scheduler".

> Keep the "error out @p's scheduler" attribution -- it is what every other
> kfunc error path does (select_cpu_from_kfunc()'s cross_task,
> scx_kf_arg_task_ok()) and it is correct for the callers that take this

Both of those error out the calling program's scheduler, not @p's. The
compat wrappers are the only ones using @p's scheduler and only because
they don't have @aux.

> +	 * which scheduler called us, so error out @p's scheduler -- but read
> +	 * it under RCU (@p's locks aren't held here) and fall back to @sch if

@p's locks are held when called from ops.select_cpu() or ops.enqueue(). The
ext.c comment's "aren't necessarily held" is the right wording.

> +		scx_error(scx_task_sched_rcu(p) ?: sch,
> +			  "__scx_bpf_select_cpu_and() must be used");

As the fallback only triggers for tasks already past sched_ext_dead() (or
idle tasks), tearing down the root scheduler doesn't make sense. How about
adding a flag to the root sched and printing a warning once instead?

Thanks.

--
tejun