linux-kernel - Re: [PATCH v5 09/16] kexec: enable KHO support for memory preservation

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: <20250409125630.GI1778492@nvidia.com>
Date: Wed, 9 Apr 2025 09:56:30 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Mike Rapoport <rppt@...nel.org>
Cc: Pratyush Yadav <ptyadav@...zon.de>,
	Changyuan Lyu <changyuanl@...gle.com>, linux-kernel@...r.kernel.org,
	graf@...zon.com, akpm@...ux-foundation.org, luto@...nel.org,
	anthony.yznaga@...cle.com, arnd@...db.de, ashish.kalra@....com,
	benh@...nel.crashing.org, bp@...en8.de, catalin.marinas@....com,
	dave.hansen@...ux.intel.com, dwmw2@...radead.org,
	ebiederm@...ssion.com, mingo@...hat.com, jgowans@...zon.com,
	corbet@....net, krzk@...nel.org, mark.rutland@....com,
	pbonzini@...hat.com, pasha.tatashin@...een.com, hpa@...or.com,
	peterz@...radead.org, robh+dt@...nel.org, robh@...nel.org,
	saravanak@...gle.com, skinsburskii@...ux.microsoft.com,
	rostedt@...dmis.org, tglx@...utronix.de, thomas.lendacky@....com,
	usama.arif@...edance.com, will@...nel.org,
	devicetree@...r.kernel.org, kexec@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
	linux-mm@...ck.org, x86@...nel.org
Subject: Re: [PATCH v5 09/16] kexec: enable KHO support for memory
 preservation

On Wed, Apr 09, 2025 at 12:06:27PM +0300, Mike Rapoport wrote:

> Now we've settled with terminology, and given that currently memdesc ==
> struct page, I think we need kho_preserve_folio(struct *folio) for actual
> struct folios and, apparently other high order allocations, and
> kho_preserve_pages(struct page *, int nr) for memblock, vmalloc and
> alloc_pages_exact.

I'm not sure that is consistent with what Matthew is trying to build,
I think we are trying to remove 'struct page' usage, especially for
compound pages. Right now, though it is confusing, folio is the right
word to encompass both page cache memory and random memdescs from
other subsystems.

Maybe next year we will get a memdesc API that will clarify this
substantially.

> On the restore path kho_restore_folio() will recreate multi-order thingy by
> doing parts of what prep_new_page() does. And kho_restore_pages() will
> recreate order-0 pages as if they were allocated from buddy.

I don't see we need two functions, folio should handle 0 order pages
just fine, and callers should generally be either not using struct
page at all or using their own memdesc/folio.

If we need a second function it would be a void * function that is for
things that need memory but have no interest in the memdesc. Arguably
this should be slab preservation. There is a corner case of preserving
slab allocations >= PAGE_SIZE that is much simpler than general slab
preservation, maybe that would be interesting..

I think we still don't really know what will be needed, so I'd stick
with folio only as that allows building the memfd and a potential slab
preservation system.

Then we can see where we get to with further patches doing
serialization of actual things.

Jason