From: Wei Yang <richard.weiyang@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Wei Yang <richard.weiyang@gmail.com>,
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
Date: Wed, 12 Jun 2024 07:23:40 +0000 [thread overview]
Message-ID: <20240612072340.hsdxusmszixebvrt@master> (raw)
In-Reply-To: <20240611111218.71e57e0f@gandalf.local.home>
On Tue, Jun 11, 2024 at 11:12:18AM -0400, Steven Rostedt wrote:
>On Tue, 11 Jun 2024 14:40:29 +0000
>Wei Yang <richard.weiyang@gmail.com> wrote:
>
>Missed this just before sending out v3 :-p
>
>> >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.
>
>It is. But because the patch adds a "+", it pushed the "8" out another tab.
>
>>
>> >+struct reserve_mem_table {
>> >+ char name[RESERVE_MEM_NAME_SIZE];
>> >+ unsigned long start;
>> >+ unsigned long size;
>>
>> phys_addr_t looks more precise?
>
>For just the start variable, correct? I'm OK with updating that.
>
Both start and size. When you look at the definition of memblock_region, both
are defined as phys_addr_t.
>>
>> >+};
>> >+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?
>
>Yes, because allocation may screw it up as well. I could add a CONFIG
>around it, so that those that do not want this could configure it out. But
>since it's just a total of (16 + 8 + 8) * 8 = 256 bytes, I'm not sure it's
>much of a worry to add the complexities to save that much space. As the
>code to save it may likely be bigger.
>
If Mike feel good to it, I am ok.
>>
>> >+
>> >+/* 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.
>
>This is what gets returned by the command line parser. It only cares if it
>is zero or not.
>
>>
>> Also, we'd better do this check before allocation.
>
>What allocation?
>
You call reserved_mem_add() after memblock_phys_alloc().
My suggestion is do those sanity check before calling memblock_phys_alloc().
>>
>> >+
>> >+ 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 ?
>
>Oops, that was the original name. I'll change that.
>
>>
>> >+ */
>> >+static int __init reserve_mem(char *p)
>> >+{
>> >+ phys_addr_t start, size, align;
>
>Hmm, I wonder if I should change size and align to unsigned long?
>
I grep the kernel, some use u64, some use unsigned long.
I think it is ok to use unsigned long here.
>> >+ 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.
>
>You mean that it has text and is not blank?
>
>>
>> Make sure command line parameters are valid before doing the allocation.
>
>You mean that size is non zero?
>
I mean do those sanity check before real allocation.
>I don't know if we care what the align is. Zero is valid.
>
memblock internal would check the alignment. If it is zero, it will change to
SMP_CACHE_BYTES with dump_stack().
>>
>> >+ 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?
>
>I guess we can do this check before the allocation, like you suggested.
>
>Thanks for the review.
>
>-- Steve
>
>
>>
>> >+}
>> >+__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
next prev parent reply other threads:[~2024-06-12 7:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 15:01 [PATCH v2 0/2] mm/memblock: Add "reserve_mem" to reserved named memory at boot up Steven Rostedt
2024-06-06 15:01 ` [PATCH v2 1/2] " Steven Rostedt
2024-06-07 19:35 ` Guilherme G. Piccoli
2024-06-11 14:40 ` Wei Yang
2024-06-11 14:58 ` Guenter Roeck
2024-06-11 15:12 ` Steven Rostedt
2024-06-11 16:30 ` Mike Rapoport
2024-06-11 17:34 ` Steven Rostedt
2024-06-11 19:39 ` Steven Rostedt
2024-06-12 7:23 ` Wei Yang [this message]
2024-06-12 15:32 ` Steven Rostedt
2024-06-12 7:30 ` Wei Yang
2024-06-12 15:28 ` Steven Rostedt
2024-06-06 15:01 ` [PATCH v2 2/2] pstore/ramoops: Add ramoops.mem_name= command line option Steven Rostedt
2024-06-07 19:38 ` Guilherme G. Piccoli
2024-06-07 19:54 ` [PATCH v2 0/2] mm/memblock: Add "reserve_mem" to reserved named memory at boot up Guilherme G. Piccoli
2024-06-10 17:02 ` Kees Cook
2024-06-10 17:08 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240612072340.hsdxusmszixebvrt@master \
--to=richard.weiyang@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=gpiccoli@igalia.com \
--cc=hpa@zytor.com \
--cc=joel@joelfernandes.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lstoakes@gmail.com \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=suleiman@google.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=torvalds@linuxfoundation.org \
--cc=vbabka@suse.cz \
--cc=vineeth@bitbyteword.org \
--cc=will@kernel.org \
--cc=wklin@google.com \
--cc=x86@kernel.org \
--cc=zwisler@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.