Re: [PATCH v5 08/29] sched/deadline: Take a deadline boost from the waiter's rt_mutex node

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

On 2026-11-10 06:14, Juri Lelli wrote:
[...]
> I am not completely sure that we want the additinal machinery below
> though, if we can find a simpler stop-gap solution until proxy execution
> makes things right.

Agreed. The deadline boost was meant as a temporary scheme. My patch
makes its copy of the donor's parameters correct, at a cost for stable.
A small fix that stops the lockup is the right size there.

> I was thinking 2 alternative potential bandaids:
>
>  1. Don't clear the parameters of a blocked waiter. Every live donor is,
>  by construction, a task blocked on an rt_mutex. Guard the
>  __dl_clear_params() calls in task_non_contending() and
>  inactive_task_timer() with p->pi_blocked_on (both sites hold pi_lock,
>  which is also what pi_blocked_on is written under). The bandwidth
>  release still happens at the 0-lag time; only the parameter wipe waits
>  until the task is no longer blocked.

I see two problems with this one.

First, __dl_clear_params() also clears dl_non_contending. In the timer
case, switched_from_dl() removed the running_bw of the sleeping task,
but left the flag set. If we skip the whole clear and the task comes
back to SCHED_DEADLINE, task_contending() sees the flag and does not add
its running_bw. running_bw would then underflow later. So only the
static parameters can wait.

Second, the wipe must still happen later. A task outside the class with
its old parameters would start its next boost from its old deadline. Its
deboost would then subtract bandwidth that was already given back, in
task_non_contending(). The natural place is where pi_blocked_on goes
back to NULL. But remove_waiter() clears it before it deboosts the
owner. So the wipe has to come after rt_mutex_adjust_prio() of the
owner, or the hang comes back. That puts deadline code and a pending
flag in the rtmutex slow path.

>  2. Even simpler, considering that the above is of course still far from
>  ideal: replenish_dl_entity() already WARNs on pi_of(dl_se)->dl_runtime
>  <= 0, and then hangs. Make the condition bail instead.

I prefer this one. It stays in deadline.c. It covers every way the
inherited parameters can reach 0.

> The deboost is
>  already in flight: the sched_setscheduler() that clears the donor's
>  parameters ends with rt_mutex_adjust_pi(), which walks the chain and
>  deboosts the owner through rt_mutex_setprio() and needs the owner's rq
>  lock to do so, which is exactly what the infinite loop holds. Bailing
>  releases it; the owner then sits throttled until the walk lands
>  (dl_task_timer() is a no-op for boosted entities) and moves it back to
>  fair. The stall is bounded by the walk's latency.

There is one path with no walk. normalize_rt_tasks() (sysrq-n) calls
__sched_setscheduler() with pi set to false. So nothing calls
rt_mutex_adjust_pi() for the donor. A throttled owner would then wait
for good, with the lock held.

As I read the code, the owner does not stay throttled, though.
update_curr_dl_se() enqueues a boosted entity again at once, with
ENQUEUE_REPLENISH. enqueue_task_dl() clears the throttle of a boosted
entity. So after the bail, the owner would stay queued on its old
deadline. It can then release the lock, which deboosts it. The fix
should keep that.

Also, a CAP_SYS_NICE user can trigger the WARN this way. With
panic_on_warn that takes the machine down. I would bail without a
warning when the entity is boosted, and keep the WARN for an entity that
is not.

v6 will replace this patch with that fix. I will test it with:
- the stress test that switches the donor in and out of the class;
- the delay before rt_mutex_adjust_pi() that locks up v7.4-rc1;
- the sysrq-n case of deadline_switch_test.

The deadline series then no longer needs "locking/rtmutex: Clone the
sort keys in rt_mutex_enqueue_pi()". That patch stays a fix of its own.

Thanks,

Mathieu


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