Re: [PATCH v2 07/21] sched/deadline: Do not release a departing sleeper's bandwidth twice

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

On 2026-11-04 17:15, sashiko-bot@kernel.org wrote:
[...]
> 
> [Severity: High]
> When switched_from_dl() takes the !p->dl.dl_non_contending branch, there is
> no pending inactive timer to run inactive_task_timer() and call
> __dl_clear_params(&p->dl) later. Does clearing only p->dl.dl_bw here leave
> the departed task permanently carrying stale deadline parameters
> (dl_runtime, dl_deadline, dl_period, dl_density, flags, runtime, and
> deadline) after it switches to another policy such as SCHED_OTHER?
> 
> Several paths in kernel/sched/deadline.c check dl_deadline, dl_runtime, or
> flags rather than dl_bw to distinguish a PI-boosted non-deadline task from
> a task with its own deadline reservation:
> 
> 1. In replenish_dl_entity(), initial replenishment for a PI-boosted task
> checks dl_se->dl_deadline == 0:
> 
> kernel/sched/deadline.c:replenish_dl_entity() {
> 	if (dl_se->dl_deadline == 0 ||
> 	    (dl_se->dl_defer_armed && dl_entity_overflow(dl_se, rq_clock(rq)))) {
> 		dl_se->deadline = rq_clock(rq) + pi_of(dl_se)->dl_deadline;
> 		dl_se->runtime = pi_of(dl_se)->dl_runtime;
> 	}
> }
> 
> If the departed task is later PI-boosted by a SCHED_DEADLINE waiter while
> holding an rt_mutex, dl_se->dl_deadline is still non-zero. If its stale
> p->dl.runtime is still positive and p->dl.deadline is still in the future,
> replenish_dl_entity() skips both the while (dl_se->runtime <= 0) loop and
> the dl_time_before(dl_se->deadline, rq_clock(rq)) check, so the boosted
> task runs with its own stale runtime and deadline instead of inheriting the
> donor's parameters. Conversely, if the task never ran as SCHED_DEADLINE
> (p->dl.deadline == 0, p->dl.runtime == 0) or its stale deadline is in the
> past, skipping the dl_se->dl_deadline == 0 initialization causes the loop
> to advance from the stale deadline and trigger a false replenishment lag
> warning.
> 
> 2. If the task previously had SCHED_FLAG_RECLAIM set in p->dl.flags,
> retaining p->dl.flags while p->dl.dl_bw == 0 causes dl_scaled_delta_exec()
> to call grub_reclaim() when the task is later PI-boosted:
> 
> kernel/sched/deadline.c:grub_reclaim() {
> 	if (u_inact + rq->dl.extra_bw > rq->dl.max_bw - dl_se->dl_bw)
> 		u_act = dl_se->dl_bw;
> 	else
> 		u_act = rq->dl.max_bw - u_inact - rq->dl.extra_bw;
> }
> 
> Whenever u_inact + rq->dl.extra_bw >= rq->dl.max_bw, u_act becomes
> dl_se->dl_bw (0), scaling execution time to 0 so the boosted task's runtime
> never depletes. Stale SCHED_FLAG_DL_OVERRUN in p->dl.flags can likewise
> deliver SIGXCPU to the boosted non-deadline task.
> 
> 3. Both task_non_contending() and task_contending() guard against
> non-deadline boosted tasks by checking dl_se->dl_runtime == 0:
> 
> kernel/sched/deadline.c:task_non_contending() {
> 	if (dl_se->dl_runtime == 0)
> 		return;
> }
> 
> Because p->dl.dl_runtime remains non-zero, blocking while PI-boosted (or
> deboosting while runnable) runs task_non_contending() using the stale
> parameters and sets p->dl.dl_non_contending = 1 with inactive_timer armed
> Even though p->dl.dl_bw is 0 at that moment, if the task then re-enters
> SCHED_DEADLINE via sched_setattr() while sleeping and PI-boosted
> (prev_class == next_class == &dl_sched_class), __setparam_dl() assigns a
> non-zero p->dl.dl_bw while dl_non_contending is still 1 without having
> added the new bandwidth to rq->dl.running_bw, causing inactive_task_timer()
> or migrate_task_rq_dl() to underflow rq->dl.running_bw.
> 
> 4. If the departed task wakes up in SCHED_OTHER and later switches back to
> SCHED_DEADLINE while runnable before its old p->dl.deadline passes,
> enqueue_dl_entity() checks dl_time_before(dl_se->deadline, rq_clock(rq)):
> 
> kernel/sched/deadline.c:enqueue_dl_entity() {
> 	} else if ((flags & ENQUEUE_MOVE) &&
> 		   !is_dl_boosted(dl_se) &&
> 		   dl_time_before(dl_se->deadline, rq_clock(rq_of_dl_se(dl_se)))) {
> 		setup_new_dl_entity(dl_se);
> 	}
> }
> 
> Because the stale p->dl.deadline is still in the future,
> setup_new_dl_entity() is skipped and the task reuses its old unspent
> runtime.
> 
> Should switched_from_dl() clear the remaining deadline parameters (or reset
> them once any PI donor relationship is adjusted) instead of leaving them
> populated when no inactive timer is pending?
> 

The baseline keeps them on this path as well, and so does the inactive
timer path until the 0-lag time. v3 clears the state of the period with
the bandwidth (throttle, yield, overrun, flags, deadline, runtime), which
settles (2) and (4); (3) cannot start, the zeroed deadline and runtime
putting the 0-lag time in the past, so no inactive timer is armed for
such a task; and __setparam_dl() changes the runqueue's sums on re-entry
(patch 20 of v3). (1) is a lag warning at the next boost at most. Clearing
dl_runtime, dl_deadline and dl_period needs the donor window closed first,
which is a follow-up.

Thanks,

Mathieu

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