Re: sched/deadline: total_bw leak when a task leaves SCHED_DEADLINE while not queued

[Juri Lelli]

On 30/10/26 14:47, Tejun Heo wrote:
> Hello, Juri.
> 
> On Fri, Oct 30, 2026 at 10:22:43AM +0100, Juri Lelli wrote:
> > Does the below help?
> 
> Yes, it fixes the leak. On abf8c33470f7 with the patch, the reproducer leaks
> 0 in all three cases, and 60s of random policy churn ends with total_bw back
> at its starting value. Two problems though.

Thanks for testing and reporting the additional issues!

> sched_setattr(SCHED_OTHER) with SCHED_FLAG_KEEP_PARAMS on a sleeping
> DEADLINE task leaves it DEADLINE, but each call releases its bandwidth, and
> its exit releases it again. total_bw relative to before the task became
> DEADLINE, with a 2ms/10ms task (0.2 CPU = 209715):
> 
>   after the DEADLINE set        +209715
>   after the 1st KEEP_PARAMS call      0
>   after the 2nd                 -209715
>   after the 3rd                 -419430
>   after the task exits          -629145
> 
> After that, sched_setattr(SCHED_DEADLINE) for a new 2ms/10ms task fails with
> -EBUSY while a 3ms/10ms one is admitted, and offlining a CPU fails with
> -EBUSY.

sched_setattr(OTHER, KEEP_PARAMS) on a DEADLINE task doesn't make much
sense to me :).. I'm inclined to think we want to fail early in this
case.

> Switching a sleeping DEADLINE task to SCHED_OTHER after its CPU was offlined
> crashes in the __dl_sub() the patch adds, dividing by
> dl_bw_cpus(task_cpu(p)), which is 0 for that root domain:
> 
>   Oops: divide error: 0000 [#1] SMP NOPTI
>   RIP: 0010:switched_from_dl+0x13a/0x3e0
> 
> Unpatched mainline only leaks in this case.

This one looks like a pre-existing issue which my total_bw fix makes
worse (w/p it we leak but don't crash).

Let me see what I can do about both.

Thanks,
Juri