From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05C46C83F11 for ; Sat, 26 Aug 2023 20:04:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 048E78E0003; Sat, 26 Aug 2023 16:04:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3B2A8D0001; Sat, 26 Aug 2023 16:04:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E29A38E0003; Sat, 26 Aug 2023 16:04:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D4C6D8D0001 for ; Sat, 26 Aug 2023 16:04:30 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AB27A120250 for ; Sat, 26 Aug 2023 20:04:30 +0000 (UTC) X-FDA: 81167333100.13.15D19BD Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 0FFB92000E for ; Sat, 26 Aug 2023 20:04:27 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=TBKBzvyJ; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf13.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693080268; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IaKShj0HDSSbke0Rj0W0daDorP0wFZZwF6Gz7W02/+8=; b=vzGulITMEsUdyjHGLnyRKy9IPbhrWfiTnSJt7RJSqEFODkWtEdsY0tK8B0HYu7jyv0vU2y ChW2hXxyOWbI75JIStbVEnv6GFzfm62KOs+1PWxQgB8x1ID2tviuUxDMbFuguPFpeuMskZ 6v8pz/Ob9jANTBrzZIO5yxBpIXHe/Fo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=TBKBzvyJ; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf13.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693080268; a=rsa-sha256; cv=none; b=SX+OKD7A1xFZQO6TPusyKN5ApALFNP8Nvg5BIxwpODX15jgLgHOacnlEr2c1R7y3tVoP9v jG1BdfUHDmuChSwiZAxwwM9O+LEuDfJNtsFdWygbxyRNPmyPX6w2GKeK3lpU3YVZTLhDZs lweiKnAewYsqNNo2V3w9WpqBUgMVfJ8= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 118A662010; Sat, 26 Aug 2023 20:04:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE728C433C8; Sat, 26 Aug 2023 20:04:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1693080266; bh=sgkW/Y9kSI6wk5rqNutVKU0iLBxONqaaG3/aHIb+tjk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TBKBzvyJYGZfUE1MQBNSeMeTv3IBU1F3b5bykAeT1ELi7XzBDxJP2VFCeTkpfwEj5 6ARz/OiAsTCp/bLqGjQk5hlrZe/62OUUdzjDnhVfUSJ54T0e6QL3NFAVS2H8rSQr6/ RcDLKzJ9j96VW824keRAauu51iq1G8Q3lT5WnrvY= Date: Sat, 26 Aug 2023 22:04:23 +0200 From: Greg Kroah-Hartman To: Stanislav Kinsburskii Cc: Stanislav Kinsburskii , Derek Kiernan , Dragan Cvetic , Arnd Bergmann , Wei Liu , "K. Y. Srinivasan" , Madhavan Venkataraman , Anthony Yznaga , "Mike Rapoport (IBM)" , James Gowans , Anirudh Rayabharam , Jinank Jain , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] Introduce persistent memory pool Message-ID: <2023082619-puzzling-viewable-fa69@gregkh> References: <64e7cbf7.050a0220.114c7.b70dSMTPIN_ADDED_BROKEN@mx.google.com> <2023082506-enchanted-tripping-d1d5@gregkh> <64e8f6dd.050a0220.edb3c.c045SMTPIN_ADDED_BROKEN@mx.google.com> <2023082633-magnetize-cupcake-accc@gregkh> <64ea25cd.650a0220.642cc.50e6SMTPIN_ADDED_BROKEN@mx.google.com> <2023082620-saint-petition-bb89@gregkh> <64ea3699.170a0220.13ee0.5c3aSMTPIN_ADDED_BROKEN@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64ea3699.170a0220.13ee0.5c3aSMTPIN_ADDED_BROKEN@mx.google.com> X-Rspamd-Queue-Id: 0FFB92000E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: bice9y8mpog43fepfjmnu5tf8wew33ug X-HE-Tag: 1693080267-991824 X-HE-Meta: U2FsdGVkX188NHY5QptIDq/fpS9OOaPJG8XVANROtEGLxOJrWo40KMobrF8UYvLwy635sZWbQpvI/rG0XIsU9KexYUgkLPVVSU8eHQNn1fZ7jXoiBDzW0abUecnJgJrJRGry7tNLupL1FK/5oScDZktcd+ZUVFkVv/Nu/NYZ8AEruYaTeOiCIALTgVNL0AUdx8yprYQfaHViWquHExiUHhsn033gudP12In/ztuOl4L6bOOloYtWG1wo+a1nx78auhiOpm49YINVQ4mJoT09lOX45nyEwjnO6VN09AF75obtNzOTnq0nALnF7sPh7s2XG0VSQ9JFWsNBd2qt8Vq5qMSKolpNoEIEVZBa7bfEX61j2yHgY5dgmGZSSjFZpqFNJzmkGA3cEf1KmYG9AsgfPCar/5xNB4jyXcYVjG05EKAn0YTURnNePPMb82UOi8EIua/T5v+ivyyKJI2uQij687gHs6CxRJ/SQCK0xdE10hfrNzR2dCPQ79og4Z54mWCIFZf+PvpxfHboJ4sQ4cEKoiuG5tvEYRHqJPasMEnYnvF8T9QOKi0xriOQwrkdjhTV7ep8QPNcJI2JsrmE9CcNUpkgU0yFKIKcW4vFoln9xInlK27AL/dQQeqZXjBybJH4fRG67JXtMzzkwYIOJyoWRkGX0outTYM5yxi9pfkCIJjl9k2zzXvpZhJIC+NDgwa+uS2htAEzCHpwIlmvRF0a4/VGT+l5d40b7j+zpX3NJh+1ccH5cBz+3/3eNYmrQszL/cejUY7ZAdGslInZvfqJoAXCssaOD3/pEo2NaB2slw+iR+vj8IEkPfhPx4UNu2kMZUQOJ7i8CaAFVfQ96U6eKiV33bgFhDMfdSdKbdSf4IYaPXp2RNXlVgtZkSbtcWf4iMSAE3LLpUbGse47GYKHczpfV3VzJ31HovbKKFRcXSowxfys8PiB46y1fC5YBXxBRQSYCd8ceY8a9ANDYeN KEpu8e1I YjSwkJqvdRxLt9cHRTWrskH6MLGDmz2Vjk+rBqYx0UGsPLAV93BdxAMi1y70FKFlh1hDE3gNRGFQhtrB9ru8UKYcZHcmSiruPHnewvEp3gks6Hz/TXby1VBd4ONNzxr2cUl0mqEhxl7zHeObn/sJGMHmO+l81Kmd4mrFSV2t7v4L7I/UHMDvIwHkzrYU0XGxNWG4FLUYeubqLUAsmDMbZTBRu2qPavr0Olhx0bD3HoUB6VoiIbDyHgfvfSCj259GH8vtxnmhgr9FX/KD8dfnA+RCqlFtA2NOG5uYrTxaN70Rke08M8sNgpwjZ1mWjF7OKYld/c9O58pGQ5Sv0iFjVpMC8H0mlIi1Gu9sRXI6lksYMqzt1PaoDEF1BTw/1yjv4zVaP X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 > > > > > > > +#include > > > > > > > +#include > > > > > > > +#include > > > > > > > + > > > > > > > +#include > > > > > > > + > > > > > > > +#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