From patchwork Mon Jun 3 23:33:30 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Rostedt X-Patchwork-Id: 13684474 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 36AF0C25B78 for ; Mon, 3 Jun 2024 23:35:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B24F6B009B; Mon, 3 Jun 2024 19:35:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AEED6B009F; Mon, 3 Jun 2024 19:35:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D8C16B009B; Mon, 3 Jun 2024 19:35:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 24EC96B009C for ; Mon, 3 Jun 2024 19:35:27 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9C99F40A3B for ; Mon, 3 Jun 2024 23:35:26 +0000 (UTC) X-FDA: 82191186252.14.8CA943A Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf18.hostedemail.com (Postfix) with ESMTP id 8B31B1C000A for ; Mon, 3 Jun 2024 23:35:24 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of "SRS0=/hzC=NF=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=/hzC=NF=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717457725; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=sqyf2ycuDkFRQdk+TwruOIrb4bz/8nK2ZjD/y4zB2L4=; b=6mTOQ3PkLAKPFJfRvzJoINx4TMWCK6/HscIHaBDObk453I3Jcz0LDy2AiRpl24sjj2NqHf E0nXdxQPQnTkFrISMyVImB2/M8dhknYFixuaAxJ7YNldG8Km8/X4R/JTsAw9mPwKYoT6qq Iht6aBq0Z0XVY4VylPRjy8u3Af86Z2c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717457725; a=rsa-sha256; cv=none; b=jD0LAmQo5u/iT8Ij3qgM2a2tIYorB0I55zRLKKncOj64XMGB0WicSnjVH05OJ6fZsh+zdF tV7ZID4CAAtyHAcceUvFPpU/edMBYLe9pggvf+Ct/Fy4yMpuCuVtEHjL8MxbGc/shg5ffF 3jQlUAmeUX1KuIAQLeuCZrigXOGQous= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of "SRS0=/hzC=NF=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=/hzC=NF=goodmis.org=rostedt@kernel.org"; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D50C8CE0EC1; Mon, 3 Jun 2024 23:35:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21208C2BD10; Mon, 3 Jun 2024 23:35:20 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.97) (envelope-from ) id 1sEHE7-00000009cuy-1lvA; Mon, 03 Jun 2024 19:36:31 -0400 Message-ID: <20240603233330.801075898@goodmis.org> User-Agent: quilt/0.68 Date: Mon, 03 Jun 2024 19:33:30 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Cc: 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 Subject: [PATCH 0/2] mm/pstore: Reserve named unspecified memory across boots X-Rspam-User: X-Stat-Signature: 9q9eutkimoody7ms9dctqi4qxjn7dkj8 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8B31B1C000A X-HE-Tag: 1717457724-931682 X-HE-Meta: U2FsdGVkX1/nDGDTHffwSlM/XAt8IfoPUToL8vvOCXjcxuEg9rRcxOM6hZ6PR5CpLveYcPUtBl0DUZE1UjUaR3SFobC4YKoWbPuFpBX9UIasuUWF6DsuIt88/LODt3ZouwlqRyAWmZXNUFWb8KN0yGathOSA2cc9hr2bSgRvIfdN7pyUFDwKZqOk5/FAJOIV75hh9inStEFzp1ZrS3MkCZnUYHOZOOisLcqBl44teUS+I7p1jn3d+hSHHRdBmtIvurHbc7eTA2B8FOxEMxiUGqP3+eKZ2d5wORDhvO6hMyalHLfZi46OTJtSD0mGjN+Sw2sHNLb8X2RnXuQ60Pu8tJL4AlPpEgrXkUJqMuFH7mFXhuMUCv7EochqoS09g26xMRYw87MKQ2LlDx2j8vR1793WOnuB4I+B+vQFjrTLAslTuKhXRsRvKvQl0HiY/o/5RsY46JaUbU89WdEZbDXP5NqE7ikif0dDfIyrYjLFtUyolfLi+KklpLu5erW2C363Nke3YAwaTeFjOoSZrr129MF+u8Blr5+okF72YJ9Mu8T2p1ekh4mTnm3GRKYw0g9eDfI/RruGez20zKOlW882oS5ovzT2ZsbQZO9HmKuAr7ZCk2VPIIWUmsl7+0t/uwbccQd8ykHqe63wN3+zSDkw0ZpN71FnvWY1ZxJLQoxYFUryuuHmvjFNqKuxeKFtY3LK5kdO/tQ7Olij8q0/0GFzJj0I2iI2w3rYYtN3nHXHzXDng6CT2UB3r3/00TOXdvfiyza+DFLzKKyx8VQUp4Kee9czOz1k0I+wvckWizubasG3g+R3e02Hwpne117erIcFFmK2D7JnT1VqkmzBYTRCZwZCEPqW0gklo4mqH2E5IDQuq8jBF9WL5jvqLFSuczv1bwhwKEi7olWRzHC63DdsQExP+ubKE0qzVIrJ196F1uKfo663zll1FiHZjDSZP33+RiBrOfQxi2AgZIR7+ea b3qRcaO6 DqDT9gGufHsxwiCs+uOxhW9lF1QbPh94ybrEuSIgfXgUpB7082GrhFUg/inAX2T6BDcn1YArOLGgFr4lQRP867hpeclpA+s9nGjFKYH/RwJYDlecxB7qDTizdkIezSI4/i1VS1Kfd3O/ke5AMS1dFcyCjqHMIC41KyruBrWHrJNqZOIYkJy2lXm59Uk8dDhfPqb67muOz7Q9KfZMOPXKRgZVSL3fH65wBpn4N03AZL4GbcPspYDVGpc3yIjRp/ICzbVOswbORneLj3+A3+FHgbWT32u+wcJdPo2kG2/x8wCAhwbjUD3IgfvDLitmMQKUjnUzMqWQ2OIfc89+KwB2F82Zjakh9YKs64s9LYb9FhLq31Dc= 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: Reserve unspecified location of physical memory from kernel command line Background: In ChromeOS, we have 1 MB of pstore ramoops reserved so that we can extract dmesg output and some other information when a crash happens in the field. (This is only done when the user selects "Allow Google to collect data for improving the system"). But there are cases when there's a bug that requires more data to be retrieved to figure out what is happening. We would like to increase the pstore size, either temporarily, or maybe even permanently. The pstore on these devices are at a fixed location in RAM (as the RAM is not cleared on soft reboots nor crashes). The location is chosen by the BIOS (coreboot) and passed to the kernel via ACPI tables on x86. There's a driver that queries for this to initialize the pstore for ChromeOS: See drivers/platform/chrome/chromeos_pstore.c Problem: The problem is that, even though there's a process to change the kernel on these systems, and is done regularly to install updates, the firmware is updated much less frequently. Choosing the place in RAM also takes special care, and may be in a different address for different boards. Updating the size via firmware is a large effort and not something that many are willing to do for a temporary pstore size change. Requirement: Need a way to reserve memory that will be at a consistent location for every boot, if the kernel and system are the same. Does not need to work if rebooting to a different kernel, or if the system can change the memory layout between boots. The reserved memory can not be an hard coded address, as the same kernel / command line needs to run on several different machines. The picked memory reservation just needs to be the same for a given machine, but may be different for different machines. Solution: The solution I have come up with is to introduce a new "reserve_mem=" kernel command line. This parameter takes the following format: reserve_mem=nn:align:label Where nn is the size of memory to reserve, the align is the alignment of that memory, and label is the way for other sub-systems to find that memory. This way the kernel command line could have: reserve_mem=12M:4096:oops ramoops.mem_name=oops At boot up, the kernel will search for 12 megabytes in usable memory regions with an alignment of 4096. It will start at the highest regions and work its way down (for those old devices that want access to lower address DMA). When it finds a region, it will save it off in a small table and mark it with the "oops" label. Then the pstore ramoops sub-system could ask for that memory and location, and it will map itself there. This prototype allows for 8 different mappings (which may be overkill, 4 is probably plenty) with 16 byte size to store the label. I have tested this and it works for us to solve the above problem. We can update the kernel and command line and increase the size of pstore without needing to update the firmware, or knowing every memory layout of each board. I only tested this locally, it has not been tested in the field. Changes since the POC: https://lore.kernel.org/all/20240409210254.660888920@goodmis.org/ - Used Mike Rapoport's suggesting to use the later call to memblock_phys_alloc() instead of messing with the e820 tables. - No longer uses the " memmap" kernel command line and instead uses "reserve_mem". This also removes the issue of booting a kernel without it crashing due to "memmap" defaulting to using only the specified memory when it doesn't know what the extra option is. - No longer keeping the table as __initdata so that pstore can use it via a module. - This is no longer a proof of concept patch series. Steven Rostedt (Google) (2): mm/memblock: Add "reserve_mem" to reserved named memory at boot up pstore/ramoops: Add ramoops.mem_name= command line option ---- fs/pstore/ram.c | 15 +++++++++ include/linux/mm.h | 2 ++ mm/memblock.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 114 insertions(+)