linux-kernel - Re: [PATCH v3 6/7] mm/memblock: Use KSTATE instead of kho to preserve preserved_mem

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] [day] [month] [year] [list]

Message-ID: <20250918231419.GQ1391379@nvidia.com>
Date: Thu, 18 Sep 2025 20:14:19 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Andrey Ryabinin <ryabinin.a.a@...il.com>
Cc: Andrey Ryabinin <arbn@...dex-team.com>, linux-kernel@...r.kernel.org,
	Alexander Graf <graf@...zon.com>, Mike Rapoport <rppt@...nel.org>,
	James Gowans <jgowans@...zon.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>, Baoquan He <bhe@...hat.com>,
	kexec@...ts.infradead.org, Pratyush Yadav <ptyadav@...zon.de>,
	Pasha Tatashin <pasha.tatashin@...een.com>,
	David Rientjes <rientjes@...gle.com>,
	Pratyush Yadav <pratyush@...nel.org>,
	Changyuan Lyu <changyuanl@...gle.com>,
	Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
	Chris Li <chrisl@...nel.org>, Ashish.Kalra@....com,
	William Tu <witu@...dia.com>, David Matlack <dmatlack@...gle.com>
Subject: Re: [PATCH v3 6/7] mm/memblock: Use KSTATE instead of kho to
 preserve preserved_mem_table

On Thu, Sep 18, 2025 at 09:00:31PM +0200, Andrey Ryabinin wrote:

> By contrast, KSTATE centralizes this logic. It avoids duplicating code
> and lets us express the preservation details declaratively instead
> of re-implementing them per struct.

I didn't really see it centralize much of anything, it is just a long
way to spell "memcpy" the way it is being shown here.

I'm all for consolidating, but please do actually show some
consolidation..

> On the versioning side:
> With this approach, introducing a new ABI version (say, abi_map_v1)
> would require us to maintain restore logic for each supported version,
> and carefully handle upgrades between them.

Yes, you MUST do this. It cannot be magically avoided.
 
> With KSTATE, versioning is built in. For example, adding a new field can
> simply be expressed as:

No, it isn't. The code still has to process versions and still has to
understand what to do when the unpacked struct didn't have its fields
written.

If anything it is making it more obfuscated and complicated to tell if
the comparability is done correctly or not.

Jason