Re: [PATCH sched_ext/for-7.1-fixes] sched_ext: Drop %NONE early return in scx_disable_and_exit_task()

[Andrea Righi <arighi@nvidia.com>]

Hi Tejun,

On Tue, May 12, 2026 at 08:30:18AM -1000, Tejun Heo wrote:
> d3e73a0808dd ("sched_ext: Handle SCX_TASK_NONE in disable/switched_from
> paths") skipped the trailing scx_set_task_sched(p, NULL) on %NONE tasks.
> After scx_fail_parent() parks a task at %NONE/sched=parent and the
> parent is later freed via queue_rcu_work() during root_disable, the
> preserved p->scx.sched dangles - print_scx_info() from sched_show_task()
> reads sch->ops.name from freed memory.
> 
> Drop the early return. __scx_disable_and_exit_task() already short-
> circuits on %NONE and the SUB_INIT block was cleared by
> scx_fail_parent()'s earlier call, so clearing p->scx.sched is the only
> work left - and the one thing the path actually needs.
> 
> Fixes: d3e73a0808dd ("sched_ext: Handle SCX_TASK_NONE in disable/switched_from paths")
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
>  kernel/sched/ext.c | 9 ---------
>  1 file changed, 9 deletions(-)
> 
> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 9354da79e162..8861b2deb504 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -3703,15 +3703,6 @@ static void scx_sub_init_cancel_task(struct scx_sched *sch, struct task_struct *
>  static void scx_disable_and_exit_task(struct scx_sched *sch,
>  				      struct task_struct *p)
>  {
> -	/*
> -	 * %NONE means @p is already detached at the SCX level (e.g. handed
> -	 * back to the parent by scx_fail_parent() with no init to undo).
> -	 * Skip to avoid clobbering scx_task_sched() and writing %NONE again
> -	 * on a state that's already %NONE.
> -	 */
> -	if (scx_get_task_state(p) == SCX_TASK_NONE)
> -		return;
> -
>  	__scx_disable_and_exit_task(sch, p);

I was wondering if a task here can have both SCX_TASK_SUB_INIT and
SCX_TASK_NONE, because in this case scx_sub_init_cancel_task() (called from the
SCX_TASK_SUB_INIT block, further down in this function) would be called for a
task that never entered the sub-sched initialization path, which would be
incorrect from a task lifecycle perspective.

But this should never happen: SCX_TASK_SUB_INIT is set in scx_sub_enable() on
tasks that just successfully passed __scx_init_task(sch, p, false) against a
child sub-sched, so those tasks are in READY/ENABLED, not NONE.

Maybe we can add something like this in the block below to make this clear:

 /*
  * SCX_TASK_SUB_INIT is only set on the sub-enable path, so it is always clear
  * when @p reaches this function with SCX_TASK_NONE.
  */

Apart than that, LGTM.

Reviewed-by: Andrea Righi <arighi@nvidia.com>

Thanks,
-Andrea