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 4A70BC25B74 for ; Tue, 4 Jun 2024 06:04:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C01A6B0088; Tue, 4 Jun 2024 02:04:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76E316B0089; Tue, 4 Jun 2024 02:04:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65DA66B008A; Tue, 4 Jun 2024 02:04:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 473A06B0088 for ; Tue, 4 Jun 2024 02:04:11 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BCE4E4084C for ; Tue, 4 Jun 2024 06:04:10 +0000 (UTC) X-FDA: 82192165860.03.11F19C6 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id D83624000A for ; Tue, 4 Jun 2024 06:04:08 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=L9YONRBB; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717481049; 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=/Ntx2IIPKE3omSgSh3xF5Q6Nwiepar9zcwS9fxblN0Q=; b=AGCB5gjwyPWxe472hizNPYvHk8z1TcVsLY09LY5zHl0D0hbgYQKHCOnxRQNhNzpPjtKw+2 Zass4PhzHko5acx+VrIrQ06ZjJmCkkc23c7Rz9cNRgCngqQmXfvM4H3Vn561q77x1aI2BV kh1wR0QzjagcWEIugZ9dkRVwHmrykak= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=L9YONRBB; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717481049; a=rsa-sha256; cv=none; b=5iYoQVdz0CdKheSd1ngOdRMtASyz3qpf7I745c/UN4GytWfcGXq1kP2GZelgtQQI+HD9/C +EMcD+1D83FndlLUI8jaZK2bv5h3H+T9wW25flGB5oVEFLHWjv6CpKLY7tjWF+ceihMoZ/ C8rZAyRJxwMlvirgG00FkC3YVIBzWII= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id F3DB961198 for ; Tue, 4 Jun 2024 06:04:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A82D0C32786 for ; Tue, 4 Jun 2024 06:04:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717481047; bh=M4B30GIS1d4lGziHl2ETRAmpCx3XEZtVoNK45XulINE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=L9YONRBBvOyMLNAxTKGyxKrbkg5yDz5lKVyT/qK/teTXo3O/Coa90mwmoDF6gldfZ 549bZ0rtqFr0xSJEK9zQrls4yBpqvFYw2RCRynJvUIt7ZclNHyzPMACWbx5NuC0yk4 H9zlo4T0NwCR0H4F6tNNurbKzj7bHbBqnMngubuq+bs1YYwpsORpVtyf1vSV0ANwj0 2cnTDPxIQ5iitlGxygFMoAL+PvyR5NarSWwqa9h3MRnlgF7NwNvsqrt6bes2Z/vlz5 gp1FJrx31sV2EszXnZPxcOhZIADgRLMe0TcIdkmVyOE8Two0WsFw7u1f3FX5mM8sd3 0I1s/FHoLPH3g== Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2eabd22d3f4so6137271fa.1 for ; Mon, 03 Jun 2024 23:04:07 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWScy+Y6cqZzY0xsbbSwZhkl1cp66tOQ9zzTwD74ZhpJ+E2KSYKF3f1ZCwOIe+1vGhR/j2ludbELItX/hkydY7j3uE= X-Gm-Message-State: AOJu0Yyi/kZnpJacclZ5AlQnH0eLJqBwiws7p83rR4YBv1PI6tDVYw6w Pm9QB5mspBNTVcSTbED7BCmHx9hSWLzGejLJqUvvZatE1pEYUnXdgvfRd2hbW3meJfjLhXDawTS W9b4yZjhVE6Ol7BFmf8lVoCTBN6s= X-Google-Smtp-Source: AGHT+IHVlviNMyuiDTy8BXSpmmQsquH1nttnEqb9GRM155e1DzpJqqQMSfDQX+2d+pZK5cfpuPeWpv6RYnrY2Ix/7UU= X-Received: by 2002:a2e:980d:0:b0:2d8:67a0:61b2 with SMTP id 38308e7fff4ca-2ea9512c01dmr60165791fa.20.1717481045999; Mon, 03 Jun 2024 23:04:05 -0700 (PDT) MIME-Version: 1.0 References: <20240603233330.801075898@goodmis.org> <20240603233631.452433539@goodmis.org> In-Reply-To: <20240603233631.452433539@goodmis.org> From: Ard Biesheuvel Date: Tue, 4 Jun 2024 08:03:54 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] mm/memblock: Add "reserve_mem" to reserved named memory at boot up To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Kees Cook , Tony Luck , "Guilherme G. Piccoli" , linux-hardening@vger.kernel.org, Guenter Roeck , Ross Zwisler , wklin@google.com, Vineeth Remanan Pillai , Joel Fernandes , Suleiman Souhlal , Linus Torvalds , Catalin Marinas , Will Deacon , Mike Rapoport Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: D83624000A X-Stat-Signature: tto4zd1qtwyqy1g13byfuze5ti5exr51 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1717481048-981998 X-HE-Meta: U2FsdGVkX18XjISfryrMf33EYUwK2U6vMMvwUPYYLSSMarPBi6KDA89DDZU4Isp/vYabHqKOcdrU4yrJ+a0kSENg2jKDiep+XXGPLGVXdLyWD5vvFFqPwvV4vSQcIpqr8IPdCqt/HHV8RAG0ffGoancZkTaXHgbCNxpoPnv1aPXMe0+zvFMefBfSh48A+LYyoR1TtX7SmBbJaujo7OQX6+ERNk/CYf42Ct/mbGhNrF6nKBH+pII9HmO8aVO1tFTyO5BPuXnD0f2e7KI4iXVHRX/5hRVXJGRFTEv9ruJBLpKs1Z31CZSHXuLbaWU+gIWsv9kRlqCqCggYenvr7vktXZH3p9b3/o8bY3LBKsLviQu5JCVfR12FoxXi2qQlCnQevBXzrEAnu/XriX15HerOqCcQZw+WQVSBY3IbwGq3Ebjf87IDhmjD7JAnAFLLMdV5i+yvIo//GZO5LHArxxnfck+GfyrLAj5QIPdAyNrQhJaYmJCCispzkDMgVSiq8nxWAWR8E+4cxXMPpic8vgbeRbQdlQXVMa0eCUWIT9EzrNOcRhuY80zCfTFTmYibaekQWaAprRsfC5rPzfi0ul1Q/GUuDzTSBjUSS7t3A3hutw+ysIENAAmfCE7rRKuSSU4ubZgbJKIjq0AC19p8dGXlDkIXVlYmvrvYk0SkrRwmJOZZ7S66tTrT+69L8zVhFf3GltSk/O/ka8ab1B14WAxJbs4qIMZTa9i/J77tjJ8xWMUWw3S2TzHg+vInqzHnVo2Ru49n6rszmY6VAX4zh/4Rc+xYDFGgPklKREHJ3a3mzxe4ggLAOrp4igV3ulWiwNRX5zMKO3GsgNL3CnbW2IZ1nQizkHGt96FNoXuH9Gd21aZ5sYFH1A0o4pLvrrUEqQ/sXUKnCQWfJE4Ghc5NYWL5LfSmxQYSkwNdSgIZrybDJa4HhbVcALdoROlnoV2lRB0YadFFnYZ8Sdc48AQmzXR IADi2geA kj8B9EaloU9H9Mm0xuD2NV890mly6eLu8QSBsyzQsQUVSmBB77ceawyqgdoKRYJkGhpm66BiduadYFkt5KyfsW32kjvc+Mai3UOO5CBw9HFcaspUtt7JlDlik90rWi4KliVwy7MEotA8SYoTrM8gMUldEa9TLMHPa45Mm0ChvBCaNtjLFkSg2wd/5hxH3OYn33kLxa7Jek6TO57rWW9ZCN3Ax3c5JdwaYJv01Xs0lB6v+irhwNFE1rneeIBEQTattquO8VcZnFQMvyYlVYi0CTEYPZpJoLJ3Kyw88tAv7t+kOr1CDkpDayHqo0sYVOJ2uYbl3YjAbYy6i1K/UIF20nLhGD9/tiOoy9xe4AIou+xlLrUbnuBXW7TSwmdpkWh4RK+zK 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: List-Subscribe: List-Unsubscribe: On Tue, 4 Jun 2024 at 01:35, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > 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 > > Link: https://lore.kernel.org/all/ZjJVnZUX3NZiGW6q@kernel.org/ > > Suggested-by: Mike Rapoport > Signed-off-by: Steven Rostedt (Google) You failed to point out in the commit message that the assumption here is that this memory will retain its contents across a soft reboot. Or am I misunderstanding this? In any case, as I pointed out before, playing these games unilaterally from the kernel side, i.e., without any awareness whatsoever from the firmware and bootloader (which will not attempt to preserve RAM contents), is likely to have a rather disappointing success ratio in the general case. I understand this may be different for vertically integrated software stacks like ChromeOS so perhaps it should live there as a feature. Then, as Kees points out, there is also the risk that the kernel itself may be stepping on this memory before having realized that it is reserved. At least ARM and x86 have decompressors with a substantial amount of non-trivial placement logic that would need to be made aware of this reservation. Note that EFI vs. non-EFI boot also makes a difference here. > --- > include/linux/mm.h | 2 + > mm/memblock.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 99 insertions(+) > > 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 > +struct reserve_mem_table { > + char name[RESERVE_MEM_NAME_SIZE]; > + unsigned long start; > + unsigned long size; > +}; > +static struct reserve_mem_table reserved_mem_table[RESERVE_MEM_MAX_ENTRIES]; > +static int reserved_mem_count; > + > +/* 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; > + > + 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 > + */ > +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; > + > + 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; > +} > +__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 > > >