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

[Marek Szyprowski]

On 05.11.2026 11:38, Juri Lelli wrote:
> 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/

I've applied the whole patchset and ran my tests. Everything works fine now. Thanks!

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland