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: <febd10dae881f29fa8236f3e2d6ad77a8f094d72.camel@infradead.org>
Date: Sat, 14 Dec 2024 09:57:47 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>, Thomas Gleixner
	 <tglx@...utronix.de>
Cc: 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 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/
we'd probably need to actually mount something and maybe do some disk
I/O.

(Which means the fact that the initrd can rebuild itself with cpio is
no longer quite so useful, as it could have just loaded the initrd for
the next kernel from the file system. But I already did that part, so
whatever.)


 $ cat init
#!/bin/sh

find . > files.txt
mount -tproc none /proc

cat /proc/sys/kernel/watchdog_thresh
echo 20 >  /proc/sys/kernel/watchdog_thresh

mount -tramfs none /tmp
NEXTCOUNT=$(($LOOPCOUNT+1))
CMDLINE=$(cat /proc/cmdline)
NEWCMDLINE="${CMDLINE/LOOPCOUNT=$LOOPCOUNT/} LOOPCOUNT=$NEXTCOUNT"

echo KEXEC LOOP $LOOPCOUNT
echo $NEWCMDLINE

cpio --quiet -H newc -o < files.txt | gzip -n9 > /tmp/initramfs.gz
kexec -f /bzImage --initrd /tmp/initramfs.gz --append "$NEWCMDLINE"


 $ cp ~/git/linux/arch/x86/boot/bzImage .
 $ find . | cpio --quiet -H newc -o  | gzip -n9 > ../kexec.initramfs
 $ ls -d `find .`
.              ./bin/mount              ./lib64/ld-linux-x86-64.so.2
./bin          ./bin/sh                 ./lib64/libc.so.6
./bin/busybox  ./bin/sleep              ./lib64/liblzma.so.5
./bin/cat      ./dev                    ./lib64/liblzma.so.5.4.4
./bin/cpio     ./dev/console            ./lib64/libz.so.1
./bin/echo     ./dev/null               ./lib64/libz.so.1.2.13
./bin/find     ./dev/ttyS5              ./loadret
./bin/gzip     ./init                   ./loadret.c
./bin/kexec    ./init.preserve-context  ./proc
./bin/mknod    ./lib64                  ./tmp


Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)