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-=wi=GNaLzNt5zjee6m9OHNvr=Sc1S-xsnS0cNMfdVp15hg@mail.gmail.com>
Date: Mon, 31 Mar 2025 18:30:33 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Jann Horn <jannh@...gle.com>, 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, Matthew Wilcox <willy@...radead.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 18:01, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Note, I believe that Linus brought up the issue that because this physical
> memory is not currently part of the memory allocator (it's not aware of it
> yet), that the getting struct page or a "pfn" for it may not be reliable.

'pfn' is always reliable.

The pfn ('page frame number') is literally just the physical address
expressed in 'page units', ie just shifted down by the page shift.

So pfn and phys_addr_t are interchangeable when it comes to mapping
pages. The pfn is in fact often the preferred form, because on 32-bit
architectures a pfn is 32-bit, but a phys_addr_t is often 64-bit and
generates extra code.

I think 'pfn' was introduced as a name ong long ago because it was
what the alpha architecture used in the VM documentation. It probably
predates that too, but it's where I got it from, iirc.

              Linus