Re: [PATCH v2 sched_ext/for-7.3 24/36] sched_ext: Add reject DSQ for cap-rejected dispatches

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] Kernel-forced bypass to the local DSQ on offline CPUs interacts with capability rejection to create an unrecoverable infinite scheduling loop.
- [High] Unbounded task re-rejection in `scx_reenq_reject()` creates a hardirq storm that can starve the stall watchdog and deadlock the system.
- [Medium] Missing `p->migration_pending` bypass in `scx_local_or_reject_dsq()` leads to spurious rejections and stranded migrating tasks.
--

commit cc43ff2d97ed53171db67ffa05cfd948c7786c2a
Author: Tejun Heo <tj@kernel.org>

sched_ext: Add reject DSQ for cap-rejected dispatches

When a sub-scheduler dispatches a task to a CPU it lacks the required
capability on, the task must be rejected rather than allowed to run.
This patch adds the machinery for that with a reject DSQ.

> diff --git a/kernel/sched/ext/sub.c b/kernel/sched/ext/sub.c
> index deb4c802af83a..e79d30aba0cc0 100644
> --- a/kernel/sched/ext/sub.c
> +++ b/kernel/sched/ext/sub.c

[ ... ]

> @@ -208,6 +208,116 @@ void scx_init_root_caps(struct scx_sched *sch)
> +struct scx_dispatch_q *scx_local_or_reject_dsq(struct scx_sched *sch, struct rq *rq,
> +					       struct task_struct *p, u64 *enq_flags)
> +{
> +	s32 cid = __scx_cpu_to_cid(cpu_of(rq));
> +	u64 missing = scx_missing_caps(sch, cpu_of(rq), scx_caps_for_enq(*enq_flags));
> +
> +	/* requirements met */
> +	if (likely(!missing))
> +		return &rq->scx.local_dsq;

[Severity: Critical]
Can this cause a permanent deadlock when offlining a CPU?

When a CPU goes offline, scx_offline_ecaps() clears ecaps to 0. If a task is
enqueued there, scx_do_enqueue_task() checks !scx_rq_online(rq) and forces
the task to the local DSQ before checking scx_bypassing().

scx_local_or_reject_dsq() will then deterministically reject the task because
missing will be non-zero. Does this create an infinite irq_work loop that
completely ignores the stall watchdog's bypass mode?

> +
> +	/*
> +	 * A migration-disabled task must run on this CPU. Let it run and count
> +	 * the violation.
> +	 */
> +	if (unlikely(is_migration_disabled(p))) {
> +		__scx_add_event(sch, SCX_EV_SUB_FORCED_ADMIT, 1);
> +		return &rq->scx.local_dsq;
> +	}

[Severity: Medium]
Should this capability check exemption also include p->migration_pending?

If a migrating task is routed to the local DSQ (e.g. via ENQUEUE_RESTORE)
and lacks capabilities, it gets diverted to the reject DSQ. When
scx_reenq_reject() processes it, it hits WARN_ON_ONCE(p->migration_pending)
and skips re-enqueueing, leaving the task stranded in the reject queue.

[ ... ]

> +void scx_reenq_reject(struct rq *rq)
> +{
> +	LIST_HEAD(tasks);
> +	struct task_struct *p, *n;

[ ... ]

> +	list_for_each_entry_safe(p, n, &tasks, scx.dsq_list.node) {
> +		list_del_init(&p->scx.dsq_list.node);
> +
> +		scx_do_enqueue_task(rq, p, SCX_ENQ_REENQ, -1);

[Severity: High]
Does this code create an unbounded hardirq storm if the BPF scheduler
repeatedly dispatches to a local DSQ without the required capabilities?

When scx_local_or_reject_dsq() diverts to reject_dsq, it calls
rq_owned_post_enq() -> schedule_deferred_locked() to queue an irq_work,
which in turn calls scx_reenq_reject().

If the BPF scheduler deterministically dispatches back to the same local DSQ,
could it trap CPUs in an irq_work self-IPI loop and starve the stall watchdog
in process context?

> +
> +		p->scx.flags &= ~SCX_TASK_REENQ_REASON_MASK;
> +	}
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706014058.439853-1-tj@kernel.org?part=24