From: David Laight <david.laight.linux@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Vincent Donnefort <vdonnefort@google.com>
Subject: Re: [PATCH v2] tracing: Do not allow mmap() of persistent ring buffer
Date: Fri, 14 Feb 2025 17:18:54 +0000 [thread overview]
Message-ID: <20250214171854.50adf509@pumpkin> (raw)
In-Reply-To: <20250214115547.0d7287d3@gandalf.local.home>
On Fri, 14 Feb 2025 11:55:47 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> From: Steven Rostedt <rostedt@goodmis.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
next prev parent reply other threads:[~2025-02-14 17:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-14 16:55 [PATCH v2] tracing: Do not allow mmap() of persistent ring buffer Steven Rostedt
2025-02-14 17:18 ` David Laight [this message]
2025-02-15 15:14 ` Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250214171854.50adf509@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=vdonnefort@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.