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

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

Hi Ingo,

On 05/11/26 12:22, Ingo Molnar wrote:
> 
> * 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.

Thanks for doing that and apologies for the noise my broken series has
caused.

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

Reviewing the above and will work on what the series doesn't cover from
my original set of (attempted) fixes.

Best,
Juri