linux-kernel - Re: [RFC PATCH] Introduce persistent memory pool

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

Message-ID: <2023082619-puzzling-viewable-fa69@gregkh>
Date:   Sat, 26 Aug 2023 22:04:23 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>
Cc:     Stanislav Kinsburskii <stanislav.kinsburskii@...il.com>,
        Derek Kiernan <derek.kiernan@....com>,
        Dragan Cvetic <dragan.cvetic@....com>,
        Arnd Bergmann <arnd@...db.de>, Wei Liu <wei.liu@...nel.org>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Madhavan Venkataraman <madvenka@...ux.microsoft.com>,
        Anthony Yznaga <anthony.yznaga@...cle.com>,
        "Mike Rapoport (IBM)" <rppt@...nel.org>,
        James Gowans <jgowans@...zon.com>,
        Anirudh Rayabharam <anrayabh@...ux.microsoft.com>,
        Jinank Jain <jinankjain@...ux.microsoft.com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] Introduce persistent memory pool

On Tue, Aug 22, 2023 at 11:21:59PM -0700, Stanislav Kinsburskii wrote:
> On Sat, Aug 26, 2023 at 07:02:12PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Aug 22, 2023 at 11:15:08PM -0700, Stanislav Kinsburskii wrote:
> > > On Sat, Aug 26, 2023 at 09:45:39AM +0200, Greg Kroah-Hartman wrote:
> > > > On Tue, Aug 22, 2023 at 06:36:10PM -0700, Stanislav Kinsburskii wrote:
> > > > > > > +#include <linux/bitmap.h>
> > > > > > > +#include <linux/memblock.h>
> > > > > > > +#include <linux/spinlock.h>
> > > > > > > +#include <linux/types.h>
> > > > > > > +
> > > > > > > +#include <linux/pmpool.h>
> > > > > > > +
> > > > > > > +#define VERSION			1
> > > > > > 
> > > > > > In kernel code does not need versions.
> > > > > > 
> > > > > 
> > > > > Could you elaborate on this? Should kernel version be used as a backward
> > > > > compatitbility marker instead?
> > > > 
> > > > kernel versions should never be checked for in-kernel code, so I really
> > > > don't understand the question here sorry.
> > > > 
> > > > For code that is in the kernel tree, having "versions" on them (as many
> > > > drivers used to, and now only a few do), makes no sense, especially with
> > > > the stable/lts trees getting fixes for them over time as well.
> > > > 
> > > 
> > > This version is rather an ABI version. The idea is to make sure, that
> > > any future ABI change is explicit and reflected in the version, so it
> > > can be easily noticed in case of kexec to a kernel with an older
> > > version.
> > > But I guess there are other ways to make sure, that the ABI contract is
> > > the preserved.
> > 
> > Which ABI are you referring to here.  The user/kernel one?  Or the
> > kernel/hypervisor one?  Or something else?
> > 
> 
> Yeah, I guess the "ABI" word in misleading here, especially the first
> letter. I mean something else: the old kernel/new kernel.
> This persistent memory pool (its metadata) is supposed to be passed
> across kexec with the data. That is probably the main difference in
> comparison to pmem or cma.
> Since the header can change its format between kernels, there should be
> a way to identify it.

Ah.  Hah, that's crazy, and it's never going to work, you need to just
test the version of the kernel that the image was created for (you have
that in the kernel already) and verify that it is the same before
loading the new one.

That way you never have to worry about any "version number", it's just
the kernel specific version number instead.

thanks,

greg k-h