Re: [PATCH 01/12] sched: Reject SCHED_FLAG_KEEP_PARAMS before reserving deadline bandwidth

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-11-04 10:30, sashiko-bot@kernel.org wrote:
[...]
> 
> Should __sched_setscheduler() also reject SCHED_FLAG_KEEP_PARAMS when
> policy != p->policy, and skip sched_dl_overflow() when
> SCHED_FLAG_KEEP_PARAMS is set?
Both, and the first one is reproducible. Thank you, this is a real bug
and not the one patch 1 fixes.

The boosted case, confirmed: __normal_prio(SCHED_DEADLINE) gives
MAX_DL_PRIO - 1, so next_class is &dl_sched_class, and a task that
priority inheritance has boosted is of that class already. prev_class ==
next_class, so the check of commit 8a70415351ba ("sched: Reject
SCHED_FLAG_KEEP_PARAMS when it would change scheduling class") does not
fire, sched_dl_overflow() takes its first branch (p->policy is still
SCHED_NORMAL, so !task_has_dl_policy(p)) and adds the bandwidth of the
request, and the skipped __setscheduler_params() never gives it to the
task. Its dl_bw stays 0, so switched_from_dl() has nothing to release at
the deboost.

A SCHED_OTHER owner of a PTHREAD_PRIO_INHERIT mutex with a slice of
40ms, boosted by a deadline waiter blocked on it, with one
sched_setattr(SCHED_DEADLINE | SCHED_FLAG_KEEP_PARAMS) on the owner:

   total_bw 419424 -> 838854 (+419430, 0.4 of a CPU), and there to stay

in 8-CPU VMs, on v7.4-rc1 with the four deadline fixes of sched/urgent
as on this series, so it predates both.

The stale parameters: also real, by reading. sys_sched_setattr() fills
the request in from the task (get_params()) with no lock held, and
dl_param_changed() then takes the stale copy for a change, so
sched_dl_overflow() moves total_bw, and this_bw and running_bw through
dl_change_utilization(), to a bandwidth the task does not have; the
release at its 0-lag time takes the task's own dl_bw and leaves the
difference behind. I have not reproduced that one: it needs a parameter
change of the task to land inside the window.

v2 will carry both fixes as two patches after patch 1:

  - refuse SCHED_FLAG_KEEP_PARAMS that would change the policy, where
    only a class change was refused before. This also closes the boosted
    case, and it stops the kernel from answering 0 to a request it
    carries out by half: SCHED_OTHER to SCHED_BATCH with
    SCHED_FLAG_KEEP_PARAMS returns 0 today and leaves the policy alone.
    That is an ABI change, so say if you would rather keep accepting it;
  - skip sched_dl_overflow() when SCHED_FLAG_KEEP_PARAMS is set, since
    there is nothing to admit for parameters that are kept. This is what
    closes the stale-parameter window.

Both carry Fixes: a509a7cd7974 ("sched/uclamp: Extend sched_setattr() to
support utilization clamping"), which added the flag and the skip of
__setscheduler_params(), and the selftest of patch 12 gains a case for
the boosted one (params_keep_boosted).

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com