Re: [PATCH 1/4] sched/deadline: Fix stale root domain in cpuset bandwidth transfer

[Juri Lelli]

Hello,

On 05/11/26 11:20, Marek Szyprowski wrote:
> On 03.11.2026 12:26, Juri Lelli wrote:
> > dl_task_needs_bw_move() and set_cpus_allowed_dl() use task_rq(p)->rd
> > to determine a task's current root domain. For a sleeping task, this
> > is stale: it points to the rq of the CPU the task last ran on, which
> > may belong to a different root domain after a cpuset move.
> >
> > This causes incorrect bandwidth accounting when a sleeping DL task is
> > moved between exclusive cpuset partitions and back:
> >
> >   1. Move root->partition: task_rq(p)->rd = root, destination in
> >      partition -> different -> bandwidth transferred correctly.
> >   2. Move partition->root: task_rq(p)->rd is still root (task never
> >      ran) -> looks like same domain -> no transfer. Partition keeps
> >      stale bandwidth, root domain is short.
> >
> > The root domain then over-admits, and when the task exits total_bw
> > underflows.
> >
> > Introduce dl_task_root_domain_cpu() helper that uses the task's
> > cpus_mask (which still reflects the old/source cpuset at call time)
> > to find the root domain where the bandwidth is actually accounted,
> > instead of relying on the potentially stale task_rq(p)->rd.
> >
> > Use cpus_mask rather than cpus_ptr, as the latter may be temporarily
> > narrowed to a single CPU by migrate_disable().
> >
> > Reported-by: Weiheng Qiu <weihengqiuu@xxxxxxxxx>
> > Closes: https://lore.kernel.org/all/14508cb2-805f-41ac-9f6b-bfd7c3d7cb1c@xxxxxxxxx/
> > Signed-off-by: Juri Lelli <juri.lelli@xxxxxxxxxx>
> This patch landed recently in linux-next as commit b4a61fdc19c5
> ("sched/deadline: Fix stale root domain in cpuset bandwidth transfer").
> I found that it triggers kernel BUG during CPU hot-plug tests on some
> of my tests boards. Reverting it on top of next-20261104 (together with
> dependent 41a7968022ca3) fixes the issue.

Others have found issues with the set and we have been working on fixes.

Can you please check if the following addresses it

https://lore.kernel.org/lkml/20261104211207.1392343-1-mathieu.desnoyers@xxxxxxxxxxxx/

Thanks,
Juri