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: <CAJZ5v0jcOCffvfB3558eJxv39aMog1BtiJ1PQG0v-sJAPuV6JQ@mail.gmail.com>
Date: Mon, 16 Dec 2024 13:14:25 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: David Woodhouse <dwmw2@...radead.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Ming Lei <ming.lei@...hat.com>, 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 Sat, Dec 14, 2024 at 10:57 AM David Woodhouse <dwmw2@...radead.org> wrote:
>
> On Fri, 2024-12-13 at 20:16 +0000, David Woodhouse wrote:
> >
> > > As discussed with Dave over IRC, the current implementation isn't
> > > actually that bad.  It might use PMSG_THAW instead of PMSG_RESTORE in
> > > kernel_kexec(), but other than this it reflects the code flow around
> > > the jump from the restore kernel to the image one during resume from
> > > hibernation.
> > >
> > > This means that hibernation and kexec jump could be unified somewhat.
> >
> > Fair enough. I'm happy to do whatever cleanups or consolidation make
> > sense, if we have a consensus.
> >
> > There remains the question of why the blk-mq thing explodes on the
> > way down for both kjump and, apparently, even the plain kexec case.
>
> In case it's of any use, here's a test case I put together recently for
> kexec stress testing.
>
>  http://david.woodhou.se/kexec.initramfs
>
> It's just an initrd I boot in qemu with '-initrd kexec.initramfs' and
> it builds a copy of itself, then kexecs back into the same kernel with
> the same initrd. You'll need to drop your own bzImage into it.
>
> It was designed to run without a block device, but to trigger the
> blk-mq thing or the one at
> https://lore.kernel.org/linux-scsi/F991D40F7D096653+20241203211857.0291ab1b@john-PC/

Which BTW includes some quite convincing analysis of what's going on.

> we'd probably need to actually mount something and maybe do some disk
> I/O.

If I'm not mistaken, this should be also reproducible by echoing
"core" into /sys/power/pm_test and running "echo disk >
/sys/power/state" in a loop after that, unless the ksys_sync()
triggered by hibernate() makes it extremely unlikely.