Re: [PATCH v5 10/29] sched/deadline: Reset the donor's runtime at a deboost in the class

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

On 2026-11-08 14:17, sashiko-bot@kernel.org wrote:
 > lost PI boost in rt_mutex_setprio() after dl_deboost() resets deadline

p->dl.deadline does not hold W1's deadline. dl_boost() copies only W1's
reservation into pi_params. The owner keeps its own deadline. A refill
during the boost adds W1's period to it. So W2's deadline is compared
with the owner's. In your case it is earlier, and the boost goes on with
W2's reservation.

A narrower case is right. A wakeup during the boost can give the owner a
period of W1's parameters. Its deadline can then be earlier than W2's.
The deboost then starts a period of its own, which can end after W2's
deadline. The next version tests the top waiter again after that reset.

 > donor runtime and deadline kept in dl_deboost() when <= dl_runtime

Known, and said in the message: "A runtime of dl_runtime or less is
kept, with its deadline. By that deadline, the task then runs at most
one runtime of its own." The second runtime comes after that deadline,
in a new period of the task's own.

 > dl_deboost() leaves deadline == 0 when task is not queued

Right. A task blocked on another rt_mutex is not queued, and the chain
walk copies the deadline 0 into its waiter node. The next version starts
the new period in dl_deboost(), from the rq clock. A new case,
deboost_blocked_keeps_order, fails on v5 and passes with the fix. The
constrained deadline check does not throttle there. With a deadline of
0, dl_next_period() is dl_period - dl_deadline. The rq clock is past it,
except in the first seconds after boot.

Thanks,

Mathieu

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