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

[Juri Lelli <juri.lelli@redhat.com>]

On 02/11/26 11:08, Juri Lelli wrote:
> 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.

Would you be able to re-test with the patches at

https://github.com/jlelli/linux.git fix/dl-total-bw-leak

BTW, it looks like I could verify with reproducers I pushed to
https://github.com/jlelli/sched-deadline-tests/commits/fix/dl-total-bw-leak-reproducer
but I'm not sure if they are similar/equivalent to what you have at your
end.

Thanks,
Juri