[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250214171854.50adf509@pumpkin>
Date: Fri, 14 Feb 2025 17:18:54 +0000
From: David Laight <david.laight.linux@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Linux Trace Kernel
<linux-trace-kernel@...r.kernel.org>, Masami Hiramatsu
<mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Vincent Donnefort <vdonnefort@...gle.com>
Subject: Re: [PATCH v2] tracing: Do not allow mmap() of persistent ring
buffer
On Fri, 14 Feb 2025 11:55:47 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:
> From: Steven Rostedt <rostedt@...dmis.org>
....
> The reason was that the code that maps the ring buffer pages to user space
> has:
>
> page = virt_to_page((void *)cpu_buffer->subbuf_ids[s]);
...
> But virt_to_page() does not work with vmap()'d memory which is what the
> persistent ring buffer has. It is rather trivial to allow this, but for
> now just disable mmap() of instances that have their ring buffer from the
> reserve_mem option.
I've recently fallen foul of the same issue elsewhere [1].
Perhaps there ought to be a variant of virt_to_page() that returns an
error for addresses outside the kernel map.
Or even a fast version that doesn't check for places where the cost
of the additional conditional would matter.
Even a kernel panic for an unchecked NULL pointer would be easier
to diagnose than the current situation.
[1] In my case it was dma_alloc_coherent() using vmalloc() when an iommu
is enabled and then the wrong things happening when I try to mmap()
the buffer into userspace (offset in both the dma buffer and the user file).
I do need to check that the iommu is honouring the buffer alignment.
David
Powered by blists - more mailing lists