Re: [PATCH sched_ext/for-7.3-fixes] sched_ext: Fix CPU hotplug hang when a dying CPU's tasks sit in the BPF scheduler

[Andrea Righi <arighi@nvidia.com>]

Hi Tejun,

On Wed, Sep 23, 2026 at 12:39:20PM -1000, Tejun Heo wrote:
> A CPU going down has to empty its own rq. Its hotplug thread waits in
> sched_cpu_wait_empty() until nothing else is left, and the only thing that
> wakes it is balance_push(), which runs from __schedule() on the dying CPU
> and pushes off the migratable tasks the CPU picks.
> 
> sched_ext breaks this. A task sitting on a user DSQ or held by the BPF
> scheduler is still counted on its rq, but an inactive CPU no longer calls
> ops.dispatch() and can't pull the task back. The dying CPU goes idle with
> the task still counted, and one of two things happens:
> 
> - Another CPU consumes the task. The rq empties without a __schedule() on
>   the dying CPU, so the hotplug thread is never woken and cpu_down() hangs
>   holding cpu_hotplug_lock.
> - The task is affine only to the dying CPU. Nothing can move it, and the
>   offline stalls until the watchdog ejects the BPF scheduler.
> 
> When the rq goes offline, re-enqueue every task on it that isn't already on
> the local DSQ. An enqueue on an offline rq lands on the local DSQ, so the
> dying CPU itself picks the tasks and balance_push() pushes them off, the
> same as for the other sched classes. From then on no sched_ext path on
> another CPU can pull a task off the rq.
> 
> ops.dispatch() currently stops as soon as the CPU goes inactive, and CPU
> hotplug then waits for an RCU grace period before taking the rq offline. A
> BPF-held task affine only to the dying CPU and preempted inside an RCU
> read-side critical section would block that grace period, and the rq would
> never go offline. Test SCX_RQ_ONLINE directly so that ops.dispatch() keeps
> running until the rq goes offline. Only the dying CPU's own hotplug thread
> clears the flag during teardown, and task_can_run_on_remote_rq() still keeps
> other rqs' tasks off the CPU.
> 
> Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class")
> Fixes: 991ef53a4832 ("sched_ext: Make scx_rq_online() also test cpu_active() in addition to SCX_RQ_ONLINE")
> Cc: stable@vger.kernel.org # v6.12+
> Reported-by: Alap Mohan <mohaalap@meta.com>
> Reported-by: Joonwoo Park <joonwoo@meta.com>
> Signed-off-by: Tejun Heo <tj@kernel.org>

This makes sense to me.

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

Thanks,
-Andrea

> ---
>  kernel/sched/ext/ext.c     |   22 ++++++++++++++++++++--
>  kernel/sched/ext/inlines.h |    8 +++++++-
>  kernel/sched/ext/sub.c     |    4 ----
>  kernel/sched/sched.h       |    5 +++--
>  4 files changed, 30 insertions(+), 9 deletions(-)
> 
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
> @@ -2123,8 +2123,8 @@ static void set_task_runnable(struct rq
>  	}
>  
>  	/*
> -	 * list_add_tail() must be used. scx_bypass() depends on tasks being
> -	 * appended to the runnable_list.
> +	 * list_add_tail() must be used. scx_bypass() and rq_offline_scx()
> +	 * depend on tasks being appended to the runnable_list.
>  	 */
>  	list_add_tail(&p->scx.runnable_node, &rq->scx.runnable_list);
>  
> @@ -3731,8 +3731,26 @@ static void rq_online_scx(struct rq *rq)
>  
>  static void rq_offline_scx(struct rq *rq)
>  {
> +	struct task_struct *p, *n;
> +
>  	rq->scx.flags &= ~SCX_RQ_ONLINE;
> +
> +	/* sched domain rebuilds call rq_offline with the CPU staying alive */
> +	if (cpu_active(cpu_of(rq)))
> +		return;
> +
>  	scx_rescue_flush(rq);
> +
> +	/*
> +	 * An offline CPU no longer calls ops.dispatch(). Re-enqueue its tasks
> +	 * onto the local DSQ so that they run here and balance_push() moves
> +	 * them off.
> +	 */
> +	list_for_each_entry_safe_reverse(p, n, &rq->scx.runnable_list, scx.runnable_node) {
> +		if (p->scx.dsq == &rq->scx.local_dsq)
> +			continue;
> +		guard(sched_change)(p, DEQUEUE_SAVE | DEQUEUE_MOVE | DEQUEUE_NOCLOCK);
> +	}
>  }
>  
>  static bool check_rq_for_timeouts(struct rq *rq)
> --- a/kernel/sched/ext/inlines.h
> +++ b/kernel/sched/ext/inlines.h
> @@ -70,7 +70,13 @@ scx_dispatch_sched(struct scx_sched *sch
>  #endif	/* CONFIG_EXT_SUB_SCHED */
>  	}
>  
> -	if (unlikely(!SCX_HAS_OP(sch, dispatch)) || !scx_rq_online(rq))
> +	/*
> +	 * scx_rq_online() can't be used. Its cpu_active() test goes false
> +	 * before CPU hotplug waits for an RCU grace period, and
> +	 * rq_offline_scx() moves this CPU's tasks to the local DSQ only after
> +	 * the wait. The grace period can depend on those tasks running.
> +	 */
> +	if (unlikely(!SCX_HAS_OP(sch, dispatch)) || !(rq->scx.flags & SCX_RQ_ONLINE))
>  		return SCX_DSP_NONE;
>  
>  	dspc->rq = rq;
> --- a/kernel/sched/ext/sub.c
> +++ b/kernel/sched/ext/sub.c
> @@ -585,10 +585,6 @@ void scx_rescue_flush(struct rq *rq)
>  
>  	lockdep_assert_rq_held(rq);
>  
> -	/* sched domain rebuilds call rq_offline with the CPU staying alive */
> -	if (cpu_active(cpu_of(rq)))
> -		return;
> -
>  	/* end the current rescue */
>  	if (rq->scx.rescue.curr)
>  		scx_task_slice_ended(rq, rq->scx.rescue.curr);
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -4205,8 +4205,9 @@ extern void balance_callbacks(struct rq
>   * after which it is enqueued again.
>   *
>   * Typically this must be called while holding task_rq_lock, since most/all
> - * properties are serialized under those locks. There is currently one
> - * exception to this rule in sched/ext which only holds rq->lock.
> + * properties are serialized under those locks. There are currently two
> + * exceptions to this rule in sched/ext which only hold rq->lock: scx_bypass()
> + * and rq_offline_scx().
>   */
>  
>  /*