linux-kernel - Re: [PATCH v2 1/2] tracing: ring-buffer: Have the ring buffer code do the vmap of physical memory

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]

Message-ID: <CAHk-=whRNxdkLC6Z91g-_RbrRsUo6K6+nvRWqccjsOycwUe_JQ@mail.gmail.com>
Date: Mon, 31 Mar 2025 14:42:38 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: 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>, Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>, 
	Kees Cook <kees@...nel.org>, Tony Luck <tony.luck@...el.com>, 
	"Guilherme G. Piccoli" <gpiccoli@...lia.com>, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 1/2] tracing: ring-buffer: Have the ring buffer code do
 the vmap of physical memory

On Mon, 31 Mar 2025 at 13:57, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Note, this only works with RAM.

That's not the issue, actually.

The issue is whether there's a 'struct page'. And "being RAM" does not
mean that a struct page exists.

For example, using "mem=" on the kernel command line will literally
limit the amount of RAM the kernel will use, and in doing so will
limit the page allocations too.

IOW, all of these kernel command line things are *subtle*.

Don't mis-use them by then making assumptions about how they work
today (or how they will work tomorrow).

> I guess you mean E820.

Yes. Thankfully it's been years since I had to use the BIOS
interfaces, so I no longer remember the exact line noise numbers...

> Mike can correct me if I'm wrong, but the memory that was stolen was actual
> memory returned by the system (E820 in x86). It reserves the memory before
> the memory allocation reserves this memory. So what reserve_mem returns is
> valid memory that can be used by memory allocator, but is currently just
> "reserved" which means it wants to prevent the allocator from using it.

That may indeed be true of reserve_mem.

That doesn't make it any better to then use it for 'struct page' when
the MM layer has explicitly been told to ignore it.

Particularly since my first reaction wasn't from "that's wrong", but
from "that's stupid". Generating that temporary array of pages is just
bogus overhead.

> In fact, if you do pull my v2[*] pull request of the ring buffer code (that
> removes this user space mapping of the persistent ring buffer logic) it
> actually adds the ability to free the memory and add it back into the memory
> allocator.

.. and *after* you've given it back to the memory allocator, and it
gets allocated using the page allocators, at that point ahead and use
'struct page' as much as you want.

Before that, don't. Even if it might work. Because you didn't allocate
it as a struct page, and for all you know it might be treated as a
different hotplug memory zone or whatever when given back.

               Linus