linux-kernel - Re: [PATCH 1/2] kho: add support for preserving vmalloc allocations

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: <20250904123032.GM470103@nvidia.com>
Date: Thu, 4 Sep 2025 09:30:32 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Mike Rapoport <rppt@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Alexander Graf <graf@...zon.com>, Baoquan He <bhe@...hat.com>,
	Changyuan Lyu <changyuanl@...gle.com>, Chris Li <chrisl@...nel.org>,
	Pasha Tatashin <pasha.tatashin@...een.com>,
	Pratyush Yadav <pratyush@...nel.org>, kexec@...ts.infradead.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] kho: add support for preserving vmalloc allocations

On Wed, Sep 03, 2025 at 10:25:02PM +0300, Mike Rapoport wrote:

> It seems that our major disagreement is about using 'folio' vs 'page' in
> the naming.

It is a folio because folio is the name for something that is a high
order page and it signals that the pointer is the head page. Which is
excatly what KHO preservation works on.

I don't know what the next step is when folio is split - presumably we
will get a new type to represent an abstract memdesc head of a high
order allocation that the lowest KHO primitives will change over to.

> I'd rather stick to the good old 'page' and when the time comes we can
> 's/page/memdesc/g' supposing Matthew actually plans for it.

I think you should just convert from the vmap page to folio for now
and most likely vmap will stop using page someday..

> This way we won't need to handle the fallback from divorce of folio from
> page. This indeed is less relevant to KHO, but there are a lot of
> folio_alloc() in LUO and PCI patches that will have to be changed to a
> different allocation apparently this year.

I'm not sure what to do about this, really we should make slab work :\

But yes whatever it gets changed into needs to have matching
restoration. Most likely we will get some kind of API to allocate
PAGE_SIZE units of frozen pages with a special memdesc, so that will
need to be paired through the preserver/restore as well.

> There is a struct page for everything that's memblock_alloc()ed. And we can
> do page list, but for large  physically contiguous allocation it does not
> make sense. 

Arguably you could make them into high order pages and preserve those..

> I'd rather replace kho_preserve_phys() with kho_preserve_memblock() and add
> a restore counterpart to properly set the struct pages for it which we lack
> now.

Sure, but my point is if memblock physical memory has struct pages
then you should be preserving the struct pages as struct pages not as
phys. Upon restoring the 64 bytes of struct page memory should be
restored back to whatever memblock expects, which will eventually
include the proper memdesc value.

Jason