linux-ext4 - Re: Lockdep warnings on kexec (virtio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z1wV9SsaVe3torbO@fedora>
Date: Fri, 13 Dec 2024 19:09:41 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: David Woodhouse <dwmw2@...radead.org>,
	Stefan Hajnoczi <stefanha@...hat.com>,
	Jason Wang <jasowang@...hat.com>, "x86@...nel.org" <x86@...nel.org>,
	hpa <hpa@...or.com>, dyoung <dyoung@...hat.com>,
	kexec <kexec@...ts.infradead.org>,
	linux-ext4 <linux-ext4@...r.kernel.org>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Stefano Garzarella <sgarzare@...hat.com>,
	eperezma <eperezma@...hat.com>, Paolo Bonzini <bonzini@...hat.com>,
	Petr Mladek <pmladek@...e.com>, John Ogness <jogness@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>, Jens Axboe <axboe@...nel.dk>
Subject: Re: Lockdep warnings on kexec (virtio_blk, hrtimers)

On Fri, Dec 13, 2024 at 11:42:59AM +0100, Thomas Gleixner wrote:
> 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.

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.


Thanks, 
Ming