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: <CAJZ5v0hBUgOB4QhhwjusRcP+jksWFL-upR5En58g9RD5+n70JA@mail.gmail.com>
Date: Fri, 13 Dec 2024 20:06:52 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>, David Woodhouse <dwmw2@...radead.org>
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>, "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: Lockdep warnings on kexec (virtio_blk, hrtimers)

On Fri, Dec 13, 2024 at 6:32 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Fri, Dec 13, 2024 at 6:05 PM Thomas Gleixner <tglx@...utronix.de> wrote:
> >
> > On Fri, Dec 13 2024 at 14:07, David Woodhouse wrote:
> > > On Fri, 2024-12-13 at 14:23 +0100, Thomas Gleixner wrote:
> > >> That's only true for the case where the new kernel takes over.
> > >>
> > >> In the case KEXEC_JUMP=n and kexec_image->preserve_context == true, then
> > >> it is supposed to align with suspend/resume and if you look at the code
> > >> then it actually mimics suspend/resume in the most dilettanteish way.
> > >
> > > Did you mean KEXEC_JUMP=y there?
> >
> > Yes, of course.
> >
> > > I spent a while the other week trying to understand the case where
> > > CONFIG_KEXEC_JUMP=n and kexec_image->preserve_context=true, and came to
> > > the conclusion that it was a mirage. Userspace can't *actually* set the
> > > KEXEC_PRESERVE_CONTEXT bit when setting up the image, if KEXEC_JUMP=n.
> > >
> > > The whole of the code path for that case is dead code. It's confusing
> > > because as discussed elsewhere, we don't just #ifdef out the whole of
> > > that dead code path, but only the bits which don't actually *compile*
> > > (like references to restore_processor_state() etc.).
> >
> > Yes, I had to stare at it quite a while. :)
> >
> > >> It's a patently bad idea to clobber the kernel with kexec jump "fixes"
> > >> instead of using the well tested and established suspend/resume
> > >> machinery.
> > >>
> > >> All it takes is to:
> > >>
> > >>     1) disable the wakeup logic
> > >>
> > >>     2) provide a mechanism to invoke machine_kexec() instead of the
> > >>        actual suspend mechanism.
> > >>
> > >> No?
> > >
> > > Agreed. The hacky proof of concept I posted earlier invoking
> > > machine_kexec() instead of suspend_ops->enter() works fine. I'll look
> > > at cleaning it up and making it not invoke all the ACPI hooks for
> > > *actual* suspend to RAM, etc.
> >
> > Something like the below? It survived an hour of loop testing.
>
> I think that this KEXEC_JUMP thing can be dropped entirely and forgotten.
>
> I'm not aware of anyone actually using it.

And now I've been made aware that it's used.  Oh well.

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.