On Sat, Dec 14, 2024 at 10:57 AM David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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.
