Re: [PATCH v2] sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Mar 02, 2026 at 11:01:00AM +0100, Juri Lelli wrote:
> Running stress-ng --schedpolicy 0 on an RT kernel on a big machine
> might lead to the following WARNINGs (edited).
> 
>  sched: DL de-boosted task PID 22725: REPLENISH flag missing
> 
>  WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8
>  ... (running_bw underflow)
>  Call trace:
>   dequeue_task_dl+0x15c/0x1f8 (P)
>   dequeue_task+0x80/0x168
>   deactivate_task+0x24/0x50
>   push_dl_task+0x264/0x2e0
>   dl_task_timer+0x1b0/0x228
>   __hrtimer_run_queues+0x188/0x378
>   hrtimer_interrupt+0xfc/0x260
>   arch_timer_handler_phys+0x34/0x60
>   handle_percpu_devid_irq+0xa4/0x230
>   generic_handle_domain_irq+0x34/0x60
>   __gic_handle_irq_from_irqson.isra.0+0x158/0x298
>   gic_handle_irq+0x28/0x80
>   call_on_irq_stack+0x30/0x48
>   do_interrupt_handler+0xdc/0xe8
>   el1_interrupt+0x44/0xc0
>   el1h_64_irq_handler+0x18/0x28
>   el1h_64_irq+0x80/0x88
>   cpuidle_enter_state+0xc4/0x520 (P)
>   cpuidle_enter+0x40/0x60
>   cpuidle_idle_call+0x13c/0x220
>   do_idle+0xa4/0x120
>   cpu_startup_entry+0x40/0x50
>   secondary_start_kernel+0xe4/0x128
>   __secondary_switched+0xc0/0xc8
> 
> The problem is that when a SCHED_DEADLINE task (lock holder) is
> changed to a lower priority class via sched_setscheduler(), it may
> fail to properly inherit the parameters of potential DEADLINE donors
> if it didn't already inherit them in the past (shorter deadline than
> donor's at that time). This might lead to bandwidth accounting
> corruption, as enqueue_task_dl() won't recognize the lock holder as
> boosted.
> 
> The scenario occurs when:
> 1. A DEADLINE task (donor) blocks on a PI mutex held by another
>    DEADLINE task (holder), but the holder doesn't inherit parameters
>    (e.g., it already has a shorter deadline)
> 2. sched_setscheduler() changes the holder from DEADLINE to a lower
>    class while still holding the mutex
> 3. The holder should now inherit DEADLINE parameters from the donor
>    and be enqueued with ENQUEUE_REPLENISH, but this doesn't happen
> 
> Fix the issue by introducing __setscheduler_dl_pi(), which detects when
> a DEADLINE (proper or boosted) task gets setscheduled to a lower
> priority class. In case, the function makes the task inherit DEADLINE
> parameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag to
> ensure proper bandwidth accounting during the next enqueue operation.
> 
> Reported-by: Bruno Goncalves <bgoncalv@redhat.com>
> Signed-off-by: Juri Lelli <juri.lelli@redhat.com>

Does this thing want a Fixes?

Also, perhaps trim the WARN to the bare minimum required?