Re: [PATCH] sched/deadline: Derive root domain from active cpu in task's cpus_ptr

From: Pingfan Liu

Date: Mon Sep 29 2025 - 21:47:50 EST


Hi Peter,

On Mon, Sep 29, 2025 at 9:54 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Mon, Sep 29, 2025 at 09:36:02PM +0800, Pingfan Liu wrote:
> > When testing kexec-reboot on a 144 cpus machine with
> > isolcpus=managed_irq,domain,1-71,73-143 in kernel command line, I
> > encounter the following bug:
> >
> > [ 97.114759] psci: CPU142 killed (polled 0 ms)
> > [ 97.333236] Failed to offline CPU143 - error=-16
> > [ 97.333246] ------------[ cut here ]------------
> > [ 97.342682] kernel BUG at kernel/cpu.c:1569!
>
> > [ 97.514379] Call trace:
> > [ 97.516874] smp_shutdown_nonboot_cpus+0x104/0x128
> > [ 97.521769] machine_shutdown+0x20/0x38
> > [ 97.525693] kernel_kexec+0xc4/0xf0
> > [ 97.529260] __do_sys_reboot+0x24c/0x278
> > [ 97.533272] __arm64_sys_reboot+0x2c/0x40
>
> > Tracking down this issue, I found that dl_bw_deactivate() returned
> > -EBUSY, which caused sched_cpu_deactivate() to fail on the last CPU.
> > When a CPU is inactive, its rd is set to def_root_domain. For an S-state
>
> You mean a blocked task?
>

Yes.

> > deadline task (in this case, "cppc_fie"), it was not migrated to CPU0,
> > and its task_rq() information is stale. As a result, its bandwidth is
> > wrongly accounted into def_root_domain during domain rebuild.
> >
> > This patch uses the rd from the run queue of still-active CPU to get the
> > correct root domain.
>

Sorry that I haven't explained it clearly. I mean the still-active CPU
in task->cpus_ptr,

> That doesn't seem right in general. What if there are multiple root
> domains; how does it know which to use?
>

In the case of task->cpus_ptr, there should be only one root domain, right?

Thanks,

Pingfan