[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgwSx8Bm6c=UEe0Xh6MvkZ9aAYhYBTwUxYk3Fu6GehHVg@mail.gmail.com>
Date: Thu, 3 Apr 2025 09:51:51 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <kees@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.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>,
Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...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 Thu, 3 Apr 2025 at 09:45, Kees Cook <kees@...nel.org> wrote:
>
> pstore tries to work with either real RAM or with iomem things. What
> is there now Currently Works Fine, but should this be using
> vmap_page_range()?
Yes, I don't see the point of using vmap() on something that is
contiguous but is made to look like a collection of random pfns.
IOW, that whole 'pages[]' array (and the kmalloc/kfree) seems pointless.
I *suspect* the history is simply that 'vmap()' predates 'vmap_page_range()'.
But maybe I'm missing something, and there is some limitation to
vmap_page_range() that I'm not seeing.
Linus
Powered by blists - more mailing lists