Lockdep warnings on kexec (virtio_blk, hrtimers)
Ming Lei
ming.lei at redhat.com
Fri Dec 13 03:48:39 PST 2024
On Fri, Dec 13, 2024 at 12:31:24PM +0100, Thomas Gleixner wrote:
> On Fri, Dec 13 2024 at 19:09, Ming Lei wrote:
> > On Fri, Dec 13, 2024 at 11:42:59AM +0100, Thomas Gleixner wrote:
> >> That's the control thread on CPU0. The hotplug thread on CPU1 is stuck
> >> here:
> >>
> >> task:cpuhp/1 state:D stack:0 pid:24 tgid:24 ppid:2 flags:0x00004000
> >> Call Trace:
> >> <TASK>
> >> __schedule+0x51f/0x1a80
> >> schedule+0x3a/0x140
> >> schedule_timeout+0x90/0x110
> >> msleep+0x2b/0x40
> >> blk_mq_hctx_notify_offline+0x160/0x3a0
> >> cpuhp_invoke_callback+0x2a8/0x6c0
> >> cpuhp_thread_fun+0x1ed/0x270
> >> smpboot_thread_fn+0xda/0x1d0
> >>
> >> So something with those blk_mq fixes went sideways.
> >
> > The cpuhp callback is just waiting for inflight IOs to be completed when
> > the irq is still live.
> >
> > It looks same with the following report:
> >
> > https://lore.kernel.org/linux-scsi/F991D40F7D096653+20241203211857.0291ab1b@john-PC/
> >
> > Still triggered in case of kexec & qemu, which should be one qemu
> > problem.
>
> I'd rather say, that's a kexec problem. On the same instance a loop test
> of suspend to ram with pm_test=core just works fine. That's equivalent
> to the kexec scenario. It goes down to syscore_suspend() and skips the
> actual suspend low level magic. It then resumes with syscore_resume()
> and brings the machine back up.
>
> That runs for 2 hours now, while the kexec muck dies within 2
> minutes....
>
> And if you look at the difference of these implementations, you might
> notice that kexec just implemented some rudimentary version of the
> actual suspend logic. Based on let's hope it works that way.
>
> This is just insane and should be rewritten to actually reuse the suspend
> mechanism, which is way better tested than this kexec jump muck.
But kexec is supposed to align with reboot/shutdown, instead of suspend,
and it is calling ->shutdown() for notifying driver & device.
Thanks,
Ming
More information about the kexec
mailing list