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
| ||
|
Message-ID: <87y10j95v7.ffs@tglx> Date: Fri, 13 Dec 2024 12:31:24 +0100 From: Thomas Gleixner <tglx@...utronix.de> To: Ming Lei <ming.lei@...hat.com> 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>, "Rafael J. Wysocki" <rafael@...nel.org> Subject: Re: Lockdep warnings on kexec (virtio_blk, hrtimers) On Fri, Dec 13 2024 at 19:09, Ming Lei wrote: > On Fri, Dec 13, 2024 at 11:42:59AM +0100, Thomas Gleixner wrote: >> 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. I'd rather say, that's a kexec problem. On the same instance a loop test of suspend to ram with pm_test=core just works fine. That's equivalent to the kexec scenario. It goes down to syscore_suspend() and skips the actual suspend low level magic. It then resumes with syscore_resume() and brings the machine back up. That runs for 2 hours now, while the kexec muck dies within 2 minutes.... And if you look at the difference of these implementations, you might notice that kexec just implemented some rudimentary version of the actual suspend logic. Based on let's hope it works that way. This is just insane and should be rewritten to actually reuse the suspend mechanism, which is way better tested than this kexec jump muck. Thanks, tglx
Powered by blists - more mailing lists