Re: [PATCH v4 sched_ext/for-7.3 24/40] sched_ext: Add sub_ecaps_updated() effective-cap change notifier

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] `scx_discard_ecaps_to_sync()` loops infinitely if the target CPU is starved by RT/DL tasks, stalling scheduler teardown.
--

--- Patch [24]: [PATCH v4 sched_ext/for-7.3 24/40] sched_ext: Add sub_ecaps_updated() effective-cap change notifier ---
commit acc58dd0c8619664f61b598c2dccb6ac82d1cc5a
Author: Tejun Heo <[email protected]>
Subject: sched_ext: Add sub_ecaps_updated() effective-cap change notifier

This patch adds a notifier for sub-scheduler effective capability
changes on a CPU. It queues syncs and processes them in dispatch
context, handling CPU hotplug by zeroing capabilities when offline and
re-syncing when online.

> diff --git a/kernel/sched/ext/sub.c b/kernel/sched/ext/sub.c
> index 80f74064ca781..f0ebf7c6e1425 100644
> --- a/kernel/sched/ext/sub.c
> +++ b/kernel/sched/ext/sub.c

[ ... ]

>  void scx_discard_ecaps_to_sync(s32 cpu, struct scx_sched_pcpu *pcpu)
>  {
> -	scoped_guard (rq_lock_irqsave, cpu_rq(cpu))
> -		scx_process_sync_ecaps(cpu_rq(cpu));
> +	struct rq *rq = cpu_rq(cpu);
>  
> -	WARN_ON_ONCE(llist_on_list(&pcpu->ecaps_to_sync_node));
> +	while (true) {
> +		scoped_guard (rq_lock_irqsave, rq) {
> +			/*
> +			 * scx_process_sync_ecaps() takes the node off the list
> +			 * before it is done accessing @pcpu but does all of it
> +			 * under the rq lock. Off-list observed under the rq
> +			 * lock guarantees that the sync is complete.
> +			 */
> +			if (!llist_on_list(&pcpu->ecaps_to_sync_node))
> +				return;
> +			/*
> +			 * Discard only when the cpu is truly down. cpu_active()
> +			 * is already set when scx_online_ecaps() queues an online
> +			 * resync while SCX_RQ_ONLINE is not - so test cpu_active(),
> +			 * or that resync would be dropped.
> +			 */
> +			if (!scx_enabled() || !cpu_active(cpu)) {
> +				discard_queued_syncs(rq);
> +				return;
> +			}
> +		}
> +		resched_cpu(cpu);
> +		msleep(1);
> +	}
>  }

[Severity: High]
Could this regression lead to an indefinite hang in
scx_discard_ecaps_to_sync() if the target CPU is starved by RT or DL tasks?

If a high-priority RT or DL task monopolizes the target CPU (for example,
if RT throttling is disabled), pick_next_task() may never fall through
to the ext_sched_class.

This prevents pick_task_scx() and balance_one() from being executed on
the target CPU, so pcpu->ecaps_to_sync_node is never processed and
removed from the list. The system_dfl_wq worker running
scx_sched_free_rcu_work() would then block forever in this while (true)
loop, leaking the scx_sched resources and stalling the sub-scheduler
teardown.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=24