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

[Ingo Molnar <mingo@kernel.org>]

* Juri Lelli <juri.lelli@redhat.com> wrote:

> 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@gmail.com>
> > > Closes: https://lore.kernel.org/all/14508cb2-805f-41ac-9f6b-bfd7c3d7cb1c@gmail.com/
> > > Signed-off-by: Juri Lelli <juri.lelli@redhat.com>
> > 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@efficios.com/

So given that the first patch triggers a crash, I've removed
these fixes from sched/urgent for the time being, waiting
for an updated series.

Mind sending a series that is strictly -stable suitable fixes only?

Thanks,

	Ingo