From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vincent Donnefort <vdonnefort@google.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Jann Horn <jannh@google.com>
Subject: [PATCH v5 0/4] tracing: Clean up persistent ring buffer code
Date: Tue, 01 Apr 2025 18:58:11 -0400 [thread overview]
Message-ID: <20250401225811.008143218@goodmis.org> (raw)
Now that I learned that the memory passed back from reserve_mem is part
of the memory allocator and just "reserved" and the memory is already
virtually mapped, it can simply use phys_to_virt() on the physical memory
that is returned to get the virtual mapping for that memory!
(Thanks Mike!)
That makes things much easier, especially since it means that the memory
returned by reserve_mem is no different than the memory retrieved by
page_alloc(). This allows that memory to be memory mapped to user space
no differently than it is mapped by the normal buffer.
This new series does the following:
- Enforce the memory mapping is page aligned (both the address and the
size). If not, it errors out.
- Use phys_to_virt() to get to the virtual memory from the reserve_mem
returned addresses. As the memory is already freed via
reserve_mem_release_by_name() and it's not mapped by vmap() anymore,
the free ring buffer code doesn't need to do anything special for
this mapping.
- Treat the buffer allocated via memmap differently. It still needs to
be virtually mapped (cannot use phys_to_virt) and it must not be
freed nor memory mapped to user space. A new flag is added when a buffer
is created this way to prevent it from ever being memory mapped to user
space and the ref count is upped so that it can never be freed.
- Use vmap_page_range() instead of using kmalloc_array() to create an array
of struct pages for vmap().
- Use flush_kernel_vmap_range() instead of flush_dcache_folio()
Changes since v4: https://lore.kernel.org/linux-trace-kernel/20250401215115.602501043@goodmis.org/
- Fixed calling free_reserve_area() twice on the same memory
Steven Rostedt (4):
tracing: Enforce the persistent ring buffer to be page aligned
tracing: Have reserve_mem use phys_to_virt() and separate from memmap buffer
tracing: Use vmap_page_range() to map memmap ring buffer
ring-buffer: Use flush_kernel_vmap_range() over flush_dcache_folio()
----
Documentation/admin-guide/kernel-parameters.txt | 2 +
Documentation/trace/debugging.rst | 2 +
kernel/trace/ring_buffer.c | 5 +-
kernel/trace/trace.c | 68 ++++++++++++++++---------
kernel/trace/trace.h | 1 +
5 files changed, 52 insertions(+), 26 deletions(-)
next reply other threads:[~2025-04-01 22:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-01 22:58 Steven Rostedt [this message]
2025-04-01 22:58 ` [PATCH v5 1/4] tracing: Enforce the persistent ring buffer to be page aligned Steven Rostedt
2025-04-02 9:21 ` Mike Rapoport
2025-04-02 14:26 ` Steven Rostedt
2025-04-02 15:01 ` Mathieu Desnoyers
2025-04-02 15:03 ` Mathieu Desnoyers
2025-04-01 22:58 ` [PATCH v5 2/4] tracing: Have reserve_mem use phys_to_virt() and separate from memmap buffer Steven Rostedt
2025-04-02 9:24 ` Mike Rapoport
2025-04-02 14:28 ` Steven Rostedt
2025-04-01 22:58 ` [PATCH v5 3/4] tracing: Use vmap_page_range() to map memmap ring buffer Steven Rostedt
2025-04-02 16:42 ` Linus Torvalds
2025-04-02 16:55 ` Steven Rostedt
2025-04-02 17:03 ` Steven Rostedt
2025-04-02 17:14 ` Steven Rostedt
2025-04-02 17:20 ` Linus Torvalds
2025-04-02 17:40 ` Steven Rostedt
2025-04-02 17:46 ` Linus Torvalds
2025-04-01 22:58 ` [PATCH v5 4/4] ring-buffer: Use flush_kernel_vmap_range() over flush_dcache_folio() Steven Rostedt
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=20250401225811.008143218@goodmis.org \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rppt@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).