linux-kernel - Re: [PATCH v6 0/2] mm/memblock: Add "reserve_mem" to reserved named memory at boot up

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 18 Jun 2024 11:43:07 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Alexander Graf <graf@...zon.com>
Cc: Ard Biesheuvel <ardb@...nel.org>, <linux-kernel@...r.kernel.org>,
 <linux-trace-kernel@...r.kernel.org>, Masami Hiramatsu
 <mhiramat@...nel.org>, Mark Rutland <mark.rutland@....com>, Mathieu
 Desnoyers <mathieu.desnoyers@...icios.com>, Andrew Morton
 <akpm@...ux-foundation.org>, Vincent Donnefort <vdonnefort@...gle.com>,
 Joel Fernandes <joel@...lfernandes.org>, Daniel Bristot de Oliveira
 <bristot@...hat.com>, Ingo Molnar <mingo@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>, <suleiman@...gle.com>, Thomas Gleixner
 <tglx@...utronix.de>, Vineeth Pillai <vineeth@...byteword.org>, Youssef
 Esmat <youssefesmat@...gle.com>, "Beau Belgrave"
 <beaub@...ux.microsoft.com>, Baoquan He <bhe@...hat.com>, "Borislav Petkov"
 <bp@...en8.de>, "Paul E. McKenney" <paulmck@...nel.org>, David Howells
 <dhowells@...hat.com>, Mike Rapoport <rppt@...nel.org>
Subject: Re: [PATCH v6 0/2] mm/memblock: Add "reserve_mem" to reserved named
 memory at boot up

On Tue, 18 Jun 2024 13:47:49 +0200
Alexander Graf <graf@...zon.com> wrote:

> IMHO the big fat disclaimer should be in the argument name. 
> "reserve_mem" to me sounds like it actually guarantees a reservation - 
> which it doesn't. Can we name it more along the lines of "debug" (to 
> indicate it's not for production data) or "phoenix" (usually gets reborn 
> out of ashes, but you can never know for sure): "debug_mem", / 
> "phoenix_mem"?

I don't see any reason it will not reserve memory. That doesn't seem to
be the issue.  What is not guaranteed is that it will be in the same
location as last time. So the name is correct. It's not
"reserve_consistent_memory" ;-)

-- Steve