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 87B00C25B78 for ; Tue, 4 Jun 2024 11:08:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAF908D0003; Tue, 4 Jun 2024 07:08:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B5F488D0002; Tue, 4 Jun 2024 07:08:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A25E28D0003; Tue, 4 Jun 2024 07:08:39 -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 83DDB8D0002 for ; Tue, 4 Jun 2024 07:08:39 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3D94B1412AE for ; Tue, 4 Jun 2024 11:08:39 +0000 (UTC) X-FDA: 82192933158.11.849BDC1 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf03.hostedemail.com (Postfix) with ESMTP id EF42C20015 for ; Tue, 4 Jun 2024 11:08:35 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.hostedemail.com: domain of "SRS0=dfpp=NG=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=dfpp=NG=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717499316; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Kto+FR1FfRpT8M9yY1Kt6Bx+gIpf1YqdKC+9P/vnGxk=; b=a45cM0jdSW8gO4xx/2zqPFmRJ+Afu5jInfgO+vEBPheElqBViLfLuJwyB5yWmAF1uz1sEs 0O9KKu/3GcyS67Lsunz1XIB1wRnCnZ3hI6+zuDpxH6+dINaI+ZCwsb2XwiKhGA3uzH+7eg T8aBsWrCBFhmrF9q4iY69JLdRmabSYU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.hostedemail.com: domain of "SRS0=dfpp=NG=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=dfpp=NG=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717499316; a=rsa-sha256; cv=none; b=1N/Zm0xIfFWHGrBXPfj0gj3oX7wpyVG+p2hQWzclEHqbRza3kyKqLpShJUusexjJbyxw0T xUnGFilfQJ8TJYrUPMf7krqp5DSSr5a6hn+wQGUM8g+sGhy+x1nxGnSyJ0GQLNFOAgnLot JB8i2p54gA4JrzZtxR7bj/fRznmXLaI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 25F65CE10D7; Tue, 4 Jun 2024 11:08:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94E82C2BBFC; Tue, 4 Jun 2024 11:08:27 +0000 (UTC) Date: Tue, 4 Jun 2024 07:08:26 -0400 From: Steven Rostedt To: Ard Biesheuvel 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 Subject: Re: [PATCH 1/2] mm/memblock: Add "reserve_mem" to reserved named memory at boot up Message-ID: <20240604070826.030c5202@gandalf.local.home> In-Reply-To: References: <20240603233330.801075898@goodmis.org> <20240603233631.452433539@goodmis.org> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: EF42C20015 X-Stat-Signature: psb7h76ftfmqgyf8qd5tcheaey567gzo X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1717499315-104699 X-HE-Meta: U2FsdGVkX1/v9TEsjMV4jXTsxD6PoIHWFuw2BRNWoZyY1E9F2rYh1C8vOTAJ6EEr37PvKJAnP1qYrmnznm/mFP8tHxdlwaC3lpJyg8d5vfPiWWMDTP8hvTtWcm+rmCnp5+Gt8HVUTNjfmKnl25uyRa3IElsAyzrS2xcPwCiav0Mjm2oW9+fLUdh9VQzMXmEoW/mhCD9RoKyvkTE9Z4761QLB5a85pK01mUW7EqVT7kTdUX6Jr2UPsrQCF+SWrTs51ABc/v8EuqoQjGQCDz0BlW78JcecpFD2tQ2BTbRDu+zgVpICmiwUuTvJ/02pExtiLdj6p7sGNW+qCY3nR5ECF8dlwr8WTPhJP3i9+yzEc3rnhLTmKL2z5mjkoUm8AgM5dKnIUl7EWDUUTuUDnfp/DRcWN67dpwV4/wh79WGwQ8++m7+CPeM3m6+k9H+2nWOMBupB6PPb7d+nJRQpg3s/Q5dECEwdsA9lxpOKYL7Wl9MrfafjnyUinNhPB3OqmRXtqfICssITE/R+v+5tC2PQ4tvEJixZ+lTqD4/gKSf/3+h1nAWMHPr02hDleS99uDpYWBorMe8YtByEWGD146dgvepy9kZ2BaHrlgZ2fstmWouvMoEr5tOLWKVTARA6GHKZmRXHqeDaWPf1LaQVJ2iF9v/0so1XUHLnNG1/rZmh6mB16ULGDGfmrPoQfyvWvOtr97OyxzntyDghU8LsKvckzKJ+ntr098x2OkEIyueY5rGA/HJ05eCTe8nuxIYOa61BLgPhnEk7PHy6I06zXUUuo7Ck9pIR/zghIHEyWnhriQuJ5gl0KFFC2lIZxrAEVJlkfu8Af+SGKCHUBL+Rx7m0bb/xM49vXFiMkQJ10AwtpYsc1zpsANGec1MowBoxqVZehmIhOo4iup7TR4VEWA8Umd8vZIKYt7TQWzF0/2RZi5scsyRN8fEBMssIRZZnpOm2VRgvi6Erd2kHfNqs3Ad YYiEkhec 24dwV2nRyHCEbj07cxmmbrAmo5Gq+toVpvuOdzzfD7mkz63PjEed1Ku05E9vIV/u3x6uTyCPDY9jgFHhcgkuZZEBwwhFbjzZidDypFaaMRaeg841ftYorCR+Ik1oWj/RD91igbN8N8vGtUC0sEXYm+1wMPmDsIZi75WxtcZ/9gng3hoC861d/YClx3pL7qTfgWMXwwlSrP+zdinKT4sNIuwnd9dpRaLxDTg2vq78o7h9e0Y7cD80WmuaTYA/gxoxTpUii4QNLsT/tKyNzzflqJRa1wfDinSE0KPF4ogIHCCYMLsy/9SEqxcMP6LBp7yVkZP6FTaJdxqWtFi0E8DPtF4VbzY/Gufck4fB2BobjZpHMqo+38fzmOuh8j4ffG1jdQC0YFEtsb+zHFQ1B6NNzInBWRZwEEHdgcu28 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 08:03:54 +0200 Ard Biesheuvel wrote: > 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? Yes that is the intention. I should update the commit message. > > 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. I have been using this on two different test machines, as well as a chromebook, and it appears to work on all ofthem. As well as for VMs. I plan on adding this to my workstation and server too (they use EFI). > > 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. Agreed. Note, it should definitely state that this is not 100% reliable, and depending on the setup it may not be reliable at all. Whatever uses it should add something to confirm that the memory is the same. If corner cases become an issue, this could be extended to work with them. We could update KASLR to be aware of this allocation. The documentation update to kernel-parameters.txt on this usage should definitely stress that this can be unreliable, and use should be tested to see if it works. And also stress that if it does work, it may not work all the time. The best usage for this is for statistical debugging. For instance, in our use case, we have 1000s of crashes that we have no idea why. If this worked only 10% of the time, the data retrieved from 100 of those crashes would be very valuable. -- Steve