From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
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 82A49C27C7A
	for <linux-mm@archiver.kernel.org>; Tue, 11 Jun 2024 14:40:36 +0000 (UTC)
Received: by kanga.kvack.org (Postfix)
	id D4A376B009D; Tue, 11 Jun 2024 10:40:35 -0400 (EDT)
Received: by kanga.kvack.org (Postfix, from userid 40)
	id CF9466B009E; Tue, 11 Jun 2024 10:40:35 -0400 (EDT)
X-Delivered-To: int-list-linux-mm@kvack.org
Received: by kanga.kvack.org (Postfix, from userid 63042)
	id B72D66B009F; Tue, 11 Jun 2024 10:40:35 -0400 (EDT)
X-Delivered-To: linux-mm@kvack.org
Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10])
	by kanga.kvack.org (Postfix) with ESMTP id 9967F6B009D
	for <linux-mm@kvack.org>; Tue, 11 Jun 2024 10:40:35 -0400 (EDT)
Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1])
	by unirelay03.hostedemail.com (Postfix) with ESMTP id 3FAD8A0F59
	for <linux-mm@kvack.org>; Tue, 11 Jun 2024 14:40:35 +0000 (UTC)
X-FDA: 82218868830.20.561961F
Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47])
	by imf18.hostedemail.com (Postfix) with ESMTP id 190DE1C000A
	for <linux-mm@kvack.org>; Tue, 11 Jun 2024 14:40:32 +0000 (UTC)
Authentication-Results: imf18.hostedemail.com;
	dkim=pass header.d=gmail.com header.s=20230601 header.b=mv3OyNrl;
	spf=pass (imf18.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com;
	s=arc-20220608; t=1718116833;
	h=from:from:sender:reply-to: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=CD74/Q6BwBYrB0ifBeus+QerIwpQuK+1OT0JxpVCDgY=;
	b=JTD7LTu5KXUynhO5B9QaV1Cr+lPcBqn09+enEcz7pC9ny6GVcFkMbWfu/Q/7ELl5JNQ5zU
	Y3KUDWxAkHu91IwdsGeB389eFW7NmqAB2eQzvEi969ICWydjOFVty8Vb39maoM9Jy8q0R2
	2HF2oxI/RLXlXdlA/KQxgKq8+pHmWDo=
ARC-Authentication-Results: i=1;
	imf18.hostedemail.com;
	dkim=pass header.d=gmail.com header.s=20230601 header.b=mv3OyNrl;
	spf=pass (imf18.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718116833; a=rsa-sha256;
	cv=none;
	b=urJ7S2w/rLbcEmjmSSlj1w8pDHmgZoP1AUJUEWISyRUDbS/ZAGNl4fGhqDRxvo1aNH+HIz
	GRsMFS8mX4DDIaSSzBX/K6f2qKG08GLmm9bprCgvpdiFj9hhCGVN3r3ddanMcFfB7UFvkw
	/RllxCTJhtvW++XVM2aOT5ZFHkV8XVc=
Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-57ca578ce8dso107983a12.2
        for <linux-mm@kvack.org>; Tue, 11 Jun 2024 07:40:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1718116831; x=1718721631; darn=kvack.org;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CD74/Q6BwBYrB0ifBeus+QerIwpQuK+1OT0JxpVCDgY=;
        b=mv3OyNrlpM6MzmnlJN/d2b2IpxCE1tqQDhIPMNBtxBfsiNuQ+3mxVjgapbRN9MnDJc
         n//TWU7W4bTJOi0d7coSHIDdpsizvzQCPI/EzCN/jg2yNSf7Ht/YJ6TG5msE7rcsqLnp
         kIDrKSIQtjW9J8PrUzLfgU6bmrpHw2GI5Yh4tBgMPSuKE55oTb6+/HH/pJeB3wBkoFoK
         wowVr0BqwEMF7SAemadQCS5obCIf+LojjrxVDP5ce9DbBYoX6wUke3rl1r1TK35vCEEb
         YXY3NnE03ohDFunBTWrXGMdjVvREEAbvFI2aKkknnahLOiI0kYcslwL263dX/YMleIkq
         WVQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1718116831; x=1718721631;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :reply-to:message-id:subject:cc:to:from:date:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=CD74/Q6BwBYrB0ifBeus+QerIwpQuK+1OT0JxpVCDgY=;
        b=Tdc52FAPuAcPAqa3szb4N4nlnfIe4dC/LEskbiBChANmgD7ZI09/0XZZP1bRQ3RFwQ
         Zv2P9ifr555WdJPoBqRPeYLO5JWq+eOPmwLfWnnkkDlAP1nLvyWD/ccrm40ZDtQiIuHK
         iC6I9iStYz/Bb+fUxB9+9uX/ouJskxFlmuoyFgSUI+3tnBan/W1HwinGQ/5W2VvFULub
         aNrqBifLkgrnsC6iaGd7OtAMstv0OXP27QvE0Y+JceDVnrarO3DXLu6NTaFeWXHp5xam
         QtYDMKclFUmcXHcd97oQ03hCLrUtJ1qjMzmhs3ucyCJ0iOm4w4WMXfRjmVJZzfCErxQU
         mOXw==
X-Forwarded-Encrypted: i=1; AJvYcCW3iURTJv6nL2N91aZPPgHoHpMeUSBSWZtVzzo2qpVVBSuY+8zxQvSGZEDTKRQmP60dVt2Nn0JkYAGvEPj3RbJS/fA=
X-Gm-Message-State: AOJu0YwsByDJlYca5+Aoy3F0A9AB2S+DtAEAExn9F2Q05I6F0+p6Fhj4
	jFMs70UEmOYpWq9R48GH1TBl/9FESLZdsEf0HV+iDdMbmx3bQrRI
X-Google-Smtp-Source: AGHT+IETTSmb9f2mSZl1DzcL730oxQUbsn9eKmJZp9/x4oOat5y9b76ZBSsAyPdKyr0ZFXTiyYPY+w==
X-Received: by 2002:a17:906:b0ce:b0:a68:d2dd:e006 with SMTP id a640c23a62f3a-a6cd6d17d61mr867037466b.17.1718116831044;
        Tue, 11 Jun 2024 07:40:31 -0700 (PDT)
Received: from localhost ([185.92.221.13])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6f34591542sm115300466b.55.2024.06.11.07.40.30
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Tue, 11 Jun 2024 07:40:30 -0700 (PDT)
Date: Tue, 11 Jun 2024 14:40:29 +0000
From: Wei Yang <richard.weiyang@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Lorenzo Stoakes <lstoakes@gmail.com>, linux-mm@kvack.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Kees Cook <keescook@chromium.org>, Tony Luck <tony.luck@intel.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	linux-hardening@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>,
	Ross Zwisler <zwisler@google.com>, wklin@google.com,
	Vineeth Remanan Pillai <vineeth@bitbyteword.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Suleiman Souhlal <suleiman@google.com>,
	Linus Torvalds <torvalds@linuxfoundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH v2 1/2] mm/memblock: Add "reserve_mem" to reserved named
 memory at boot up
Message-ID: <20240611144029.h7egl4aif5mjlrwf@master>
Reply-To: Wei Yang <richard.weiyang@gmail.com>
References: <20240606150143.876469296@goodmis.org>
 <20240606150316.751642266@goodmis.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240606150316.751642266@goodmis.org>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Rspamd-Queue-Id: 190DE1C000A
X-Rspam-User: 
X-Rspamd-Server: rspam09
X-Stat-Signature: uj8ifpcdky1kpt7on1g6y5kgbf1dqb7p
X-HE-Tag: 1718116832-4176
X-HE-Meta: U2FsdGVkX1+2Y2dItGMFPE1IUUnu8HSRd/0a5iw5qr0fwJh99nltr7TTQZbDZLnrkyJs5vYuX0AYqVzRXS27hQ7n9iK1JOu8jzv1iS0+9CMwuvB7Dnb6et3YD/7Wx1MBB3PSiLBdR6RkADH+lnRiVIquyNE9ta5X4gHryIxHLabeA/5ktUZ9YQ4GWa4AUQ9q+xusHE6UNH4m0H7t+8R2ImzDvvnO3+EtO3nfSSLf3yEBFcTBLxqw8Eq/Q5sush1a72Hpoqz7bLkTAcBDjTttnU8fQz4ARk9J07O27h+alnWoxJ3xask9pSOrY7tzO+O+wHFLLGek+SV1oTsapHcDyPOFW48PcLGVhV4X89A7gA2ifdGhL6c7JuKuu4LHTr6NxOJWs/tWWDR7M5KIO8INVMTy/+FadrtsUrUI6BZLIvEp2JO4JmyLX4rsgPZ8yfNMsLvTxXMfROwqm/SppaguvsWV+sB6VTU5YCX3GfCZLiuYPrwenzuZDPI/R6vDs0nHb7Eo6vSAU8vCYi1ltH94DILNQu+p6rJNtqsOuFZqT0LeD7PvFymLAS7R6gp6xbSGkhedU+sy+evC9zF1JSCJkMjJIQ0+HCPDEhoX3A0K9MeAkRqFOTW9WsoD/FuJe/fzC2GKXhes4cf397BbDf9zsa+nYfpISBsw1yrx4yPh89/uJk1T8W8Z0ilY83Ed98abB8MEWz6M+OcuZM9sFfEjgHgqZD10k7nx2MUdC4CT/Z2yNpYmIF/nniR6ROQso+wRHyHpMpf5j9kfAWo74WoUKD7bSwiIbldfIHL0q4XhAwa8mERNs3lhas15ub860T0ONNA3M80V8KGRTJ/koFiZ+GklT+TAYk/euTEX/jDof2nLXB1oCpOkHs1WeBlWHn/gdYE1v66FCgoWqzU2xS7v3rI7xpFmklcUghtTRH/szjTpxMLMJSWqRCCuFZuf7eaiJjyO8GHbr3kDi2jd4+g
 f3Q8NuVn
 rv6CtaQe+Rj5OyjPWjYre8Ac+PpYgc1G8f0I7Fwlf+axPlMRZk5/OmukUztdSanCl2AuCeMSlRVGEVhWmxMUCgtAbZUDPlat8VLQIh347PCah8cda1vlStQ6bm1mou5167fkky6SjjavsWrKZi5OIQF5hWoYdoHCowYO9MANMjGg+DRR052q95jaSbAuEb6lZJsE+gbyv6JOkFrEi7wjR2NXlZxPpR2naUqZIsSVfdo0nsiXTneT/yYBTSXU+0lBs6dKZ0u0QvqygiFUKUvcI+9X7k4K4q5FgKBfgezAf2zSmTTfI8nZ0yTHlUIeKAJAGEOIQT8VdvPLPVssn5nyDNkm9jbrA/60csfq6VtjbSA5ywyXZDB7H0gmZmXiWtPKic9+LZnvWca2KeYFMFMzggaKYS5QLdRbn6w+NYlmTPXpU1X4qSqp0nd4trFNzPSSFmkUrnZF26KCFAixyjeCXw+UXpwjJ4rcDJIsm63IiKJ19K1tZDeDl9hyPPPf8MHOU3Lx8z76E9U1v9sfrYrBHhwFG/sQGb6IwyAN+qtW9G/H18A4V6ETTYL8a5VP38sRlj6SZ/LktTLCgMRMpDvSiFJ/M4y/kzCtLSNhKQ/Jx1ylw8PhX+vQqE18Yj5UvNqxC9htnMboNunk+9mCTBzca7aqtNzjufXj8wq5h6hseYbdiei2LdAQh2S/w9wc3ioyclhBD
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: <linux-mm.kvack.org>
List-Subscribe: <mailto:majordomo@kvack.org>
List-Unsubscribe: <mailto:majordomo@kvack.org>

On Thu, Jun 06, 2024 at 11:01:44AM -0400, Steven Rostedt wrote:
>From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
>
>In order to allow for requesting a memory region that can be used for
>things like pstore on multiple machines where the memory layout is not the
>same, add a new option to the kernel command line called "reserve_mem".
>
>The format is:  reserve_mem=nn:align:name
>
>Where it will find nn amount of memory at the given alignment of align.
>The name field is to allow another subsystem to retrieve where the memory
>was found. For example:
>
>  reserve_mem=12M:4096:oops ramoops.mem_name=oops
>
>Where ramoops.mem_name will tell ramoops that memory was reserved for it
>via the reserve_mem option and it can find it by calling:
>
>  if (reserve_mem_find_by_name("oops", &start, &size)) {
>	// start holds the start address and size holds the size given
>
>This is typically used for systems that do not wipe the RAM, and this
>command line will try to reserve the same physical memory on soft reboots.
>Note, it is not guaranteed to be the same location. For example, if KASLR
>places the kernel at the location of where the RAM reservation was from a
>previous boot, the new reservation will be at a different location.  Any
>subsystem using this feature must add a way to verify that the contents of
>the physical memory is from a previous boot, as there may be cases where
>the memory will not be located at the same location.
>
>Not all systems may work either. There could be bit flips if the reboot
>goes through the BIOS. Using kexec to reboot the machine is likely to
>have better results in such cases.
>
>Link: https://lore.kernel.org/all/ZjJVnZUX3NZiGW6q@kernel.org/
>
>Suggested-by: Mike Rapoport <rppt@kernel.org>
>Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
>---
> .../admin-guide/kernel-parameters.txt         | 20 ++++
> include/linux/mm.h                            |  2 +
> mm/memblock.c                                 | 97 +++++++++++++++++++
> 3 files changed, 119 insertions(+)
>
>diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>index b600df82669d..4b2f7fb8de66 100644
>--- a/Documentation/admin-guide/kernel-parameters.txt
>+++ b/Documentation/admin-guide/kernel-parameters.txt
>@@ -5710,6 +5710,26 @@
> 			them.  If <base> is less than 0x10000, the region
> 			is assumed to be I/O ports; otherwise it is memory.
> 
>+	reserve_mem=	[RAM]
>+			Format: nn[KNG]:<align>:<label>
>+			Reserve physical memory and label it with a name that
>+			other subsystems can use to access it. This is typically
>+			used for systems that do not wipe the RAM, and this command
>+			line will try to reserve the same physical memory on
>+			soft reboots. Note, it is not guaranteed to be the same
>+			location. For example, if KASLR places the kernel at the
>+			location of where the RAM reservation was from a previous
>+			boot, the new reservation will be at a different location.
>+			Any subsystem using this feature must add a way to verify
>+			that the contents of the physical memory is from a previous
>+			boot, as there may be cases where the memory will not be
>+			located at the same location.
>+
>+			The format is size:align:label for example, to request
>+			12 megabytes of 4096 alignment for ramoops:
>+
>+			reserver_mem=12M:4096:oops ramoops.mem_name=oops
>+
> 	reservetop=	[X86-32,EARLY]
> 			Format: nn[KMG]
> 			Reserves a hole at the top of the kernel virtual
>diff --git a/include/linux/mm.h b/include/linux/mm.h
>index 9849dfda44d4..b4455cc02f2c 100644
>--- a/include/linux/mm.h
>+++ b/include/linux/mm.h
>@@ -4263,4 +4263,6 @@ static inline bool pfn_is_unaccepted_memory(unsigned long pfn)
> void vma_pgtable_walk_begin(struct vm_area_struct *vma);
> void vma_pgtable_walk_end(struct vm_area_struct *vma);
> 
>+int reserve_mem_find_by_name(const char *name, unsigned long *start, unsigned long *size);
>+
> #endif /* _LINUX_MM_H */
>diff --git a/mm/memblock.c b/mm/memblock.c
>index d09136e040d3..a8bf0ee9e2b4 100644
>--- a/mm/memblock.c
>+++ b/mm/memblock.c
>@@ -2244,6 +2244,103 @@ void __init memblock_free_all(void)
> 	totalram_pages_add(pages);
> }
> 
>+/* Keep a table to reserve named memory */
>+#define RESERVE_MEM_MAX_ENTRIES		8
>+#define RESERVE_MEM_NAME_SIZE		16
                                        ^
Suggest to align with previous line.

>+struct reserve_mem_table {
>+	char			name[RESERVE_MEM_NAME_SIZE];
>+	unsigned long		start;
>+	unsigned long		size;

phys_addr_t looks more precise?

>+};
>+static struct reserve_mem_table reserved_mem_table[RESERVE_MEM_MAX_ENTRIES];
>+static int reserved_mem_count;

Seems no matter we use this feature or not, these memory would be occupied?

>+
>+/* Add wildcard region with a lookup name */
>+static int __init reserved_mem_add(unsigned long start, unsigned long size,
>+				   const char *name)
>+{
>+	struct reserve_mem_table *map;
>+
>+	if (!name || !name[0] || strlen(name) >= RESERVE_MEM_NAME_SIZE)
>+		return -EINVAL;
>+
>+	if (reserved_mem_count >= RESERVE_MEM_MAX_ENTRIES)
>+		return -1;

return ENOSPC? Not good at it, but a raw value maybe not a good practice.

Also, we'd better do this check before allocation.

>+
>+	map = &reserved_mem_table[reserved_mem_count++];
>+	map->start = start;
>+	map->size = size;
>+	strscpy(map->name, name);
>+	return 0;
>+}
>+
>+/**
>+ * reserve_mem_find_by_name - Find reserved memory region with a given name
>+ * @name: The name that is attached to a reserved memory region
>+ * @start: If found, holds the start address
>+ * @size: If found, holds the size of the address.
>+ *
>+ * Returns: 1 if found or 0 if not found.
>+ */
>+int reserve_mem_find_by_name(const char *name, unsigned long *start, unsigned long *size)
>+{
>+	struct reserve_mem_table *map;
>+	int i;
>+
>+	for (i = 0; i < reserved_mem_count; i++) {
>+		map = &reserved_mem_table[i];
>+		if (!map->size)
>+			continue;
>+		if (strcmp(name, map->name) == 0) {
>+			*start = map->start;
>+			*size = map->size;
>+			return 1;
>+		}
>+	}
>+	return 0;
>+}
>+
>+/*
>+ * Parse early_reserve_mem=nn:align:name

early_reserve_mem or reserve_mem ?

>+ */
>+static int __init reserve_mem(char *p)
>+{
>+	phys_addr_t start, size, align;
>+	char *oldp;
>+	int err;
>+
>+	if (!p)
>+		return -EINVAL;
>+
>+	oldp = p;
>+	size = memparse(p, &p);
>+	if (p == oldp)
>+		return -EINVAL;
>+
>+	if (*p != ':')
>+		return -EINVAL;
>+
>+	align = memparse(p+1, &p);
>+	if (*p != ':')
>+		return -EINVAL;
>+

Better to check if the name is valid here. 

Make sure command line parameters are valid before doing the allocation.

>+	start = memblock_phys_alloc(size, align);
>+	if (!start)
>+		return -ENOMEM;
>+
>+	p++;
>+	err = reserved_mem_add(start, size, p);
>+	if (err) {
>+		memblock_phys_free(start, size);
>+		return err;
>+	}
>+
>+	p += strlen(p);
>+
>+	return *p == '\0' ? 0: -EINVAL;

We won't free the memory if return -EINVAL?

>+}
>+__setup("reserve_mem=", reserve_mem);
>+
> #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_ARCH_KEEP_MEMBLOCK)
> static const char * const flagname[] = {
> 	[ilog2(MEMBLOCK_HOTPLUG)] = "HOTPLUG",
>-- 
>2.43.0
>
>

-- 
Wei Yang
Help you, Help me