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: <52850c8dbeb7c30d5bca007998f7ffd9a9b18d0f.camel@infradead.org>
Date: Fri, 13 Dec 2024 17:17:30 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>, Ming Lei <ming.lei@...hat.com>
Cc: 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, 2024-12-13 at 18:05 +0100, Thomas Gleixner wrote:
> 
> > 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.

If I read that correctly, it's still invoking the standard platform
(e.g. ACPI) hooks for suspend-to-RAM, when it probably shouldn't?

I suspect it wants its *own* set of platform_suspend_ops, which are
mostly empty apart from the ->enter() ? 

I started looking at that, but now my eyes are currently bleeding after
seeing the existing platform_suspend_ops vs. platform_s2idle_ops
structures, which are kind of similar but not the same. And the set of
helper functions which invoke one or the other, from the barely
tolerable platform_resume_end()...

static void platform_resume_end(suspend_state_t state)
{
	if (state == PM_SUSPEND_TO_IDLE && s2idle_ops && s2idle_ops->end)
		s2idle_ops->end();
	else if (suspend_ops && suspend_ops->end)
		suspend_ops->end();
}

... to the extra-special platform_resume_noirq() which is similar
except that it needs three *different* names (_resume_noirq vs.
restore_early vs. wake):

static void platform_resume_noirq(suspend_state_t state)
{
	if (state == PM_SUSPEND_TO_IDLE) {
		if (s2idle_ops && s2idle_ops->restore_early)
			s2idle_ops->restore_early();
	} else if (suspend_ops->wake) {
		suspend_ops->wake();
	}
}

I wonder if we end up wanting a *third* set there, for the kjump_ops?
Except can we unify the structure definitions and then just *use* the
appropriate one of the three, which is either passed down or selected
using the 'state'?

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