Lockdep warnings on kexec (virtio_blk, hrtimers)

[Thomas Gleixner]

On Fri, Dec 13 2024 at 09:43, David Woodhouse wrote:
> On Fri, 2024-12-13 at 09:31 +0000, David Woodhouse wrote:
>> 
>> (gdb) p sysrq_handle_showstate('t')
>> 
>> That didn't work. Maybe if I'd actually had no_console_suspend on this
>> boot. Will try again.
>
> With your fix I get the same thing (both CPUs in idle thread). And with
> no_console_suspend on the command line, 'p sysrq_handle_showstate('t')'
> does work...
>
> [  113.462898] task:loadret         state:D stack:0     pid:707   tgid:707   ppid:531    flags:0x00004002
> [  113.463615] Call Trace:
> [  113.463841]  <TASK>
> [  113.464029]  __schedule+0x502/0x1a10
> [  113.464961]  schedule+0x3a/0x140
> [  113.465234]  schedule_timeout+0xcc/0x110
> [  113.465580]  __wait_for_common+0x91/0x1c0
> [  113.466304]  cpuhp_kick_ap_work+0x13e/0x390
> [  113.466657]  _cpu_down+0xd4/0x370
> [  113.466936]  freeze_secondary_cpus.cold+0x3f/0xd4
> [  113.467326]  kernel_kexec+0xa2/0x1a0

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.

Thanks,

        tglx