Re: [PATCH 1/2] sched_ext: Auto-register/unregister dl_server reservations

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Bypassing the overflow check for detached deadline servers allows configuring an arbitrarily large bandwidth for offline CPUs, breaking root domain admission control upon hotplug.

Pre-existing issues:
- [High] Modifying a deadline server's bandwidth via debugfs for an offline CPU causes division-by-zero crashes.
--

commit e4e3b446a7561269980e46cfd4aec61572b0cae1
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: Auto-register/unregister dl_server reservations

This commit makes deadline server bandwidth reservations dynamic by
introducing an attached/detached state. It ensures that only the currently
active scheduling policy registers its bandwidth reservation, allowing unused
bandwidth to be reclaimed without losing the configured runtime and period.

> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index ddfd6bc63ab1d..8de5f182fd659 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c

[ ... ]

> @@ -1907,13 +1918,16 @@ int dl_server_apply_params(struct sched_dl_entity *dl_se, u64 runtime, u64 perio
>  	cpus = dl_bw_cpus(cpu);
>  	cap = dl_bw_capacity(cpu);
>  
> -	if (__dl_overflow(dl_b, cap, old_bw, new_bw))
> -		return -EBUSY;
> +	if (init || dl_se->dl_bw_attached) {
> +		if (__dl_overflow(dl_b, cap, old_bw, new_bw))
> +			return -EBUSY;
> +	}

[Severity: High]
Does bypassing the overflow check for detached servers allow configuring an
invalid bandwidth?

If userspace configures a massive bandwidth for an offline CPU while the
server is detached, the overflow check is skipped. Later, when the BPF
scheduler is loaded, scx_root_enable_workfn() calls dl_server_attach_bw()
for all possible CPUs. For the offline CPU, __dl_server_attach_bw_locked()
skips its own overflow check since the CPU is not active, but it still sets
dl_bw_attached = 1.

When that CPU is later brought online, the hotplug rebuild path calls
dl_server_add_bw(), which unconditionally adds the unvalidated bandwidth to
the root domain's total_bw since dl_bw_attached is now true. Could this
force the root domain into a permanently overcommitted state and break
SCHED_DEADLINE admission control?

>  
>  	if (init) {
>  		__add_rq_bw(new_bw, &rq->dl);
>  		__dl_add(dl_b, new_bw, cpus);
> -	} else {
> +		dl_se->dl_bw_attached = 1;
> +	} else if (dl_se->dl_bw_attached) {
>  		__dl_sub(dl_b, dl_se->dl_bw, cpus);
>  		__dl_add(dl_b, new_bw, cpus);

[Severity: High]
This isn't a bug introduced by this patch, but can modifying an attached
server's bandwidth on an offline CPU cause a division by zero?

When a CPU is offline, it belongs to a root domain with zero active CPUs, so
dl_bw_cpus() returns 0. If a user modifies the runtime/period via debugfs
for an offline CPU with an attached server, we reach this update path.

Both __dl_sub() and __dl_add() divide by cpus internally:

kernel/sched/deadline.c:__dl_sub() {
    ...
    __dl_update(dl_b, (s32)tsk_bw / cpus);
}

Since cpus is 0, will this trigger a kernel panic and allow a local denial
of service?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526082954.550958-1-arighi@nvidia.com?part=1