From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH v4 0/8] ring-buffer/tracing: Save module information in persistent memory
Date: Wed, 05 Mar 2025 11:45:39 -0500 [thread overview]
Message-ID: <20250305164539.379008535@goodmis.org> (raw)
This updates the persistent instance to record what modules were
loaded and what addresses they were loaded at.
First the KASLR offset is recorded in the persistent ring buffer instead of
a text address. This can be used to calculated the address offset.
Next the persistent memory is divided up differently so that there's
a single global meta data for the entire buffer that can hold the
global data, and each per CPU meta data can just hold what it needs.
A scratch area can be created by the caller, in this case the tracing
system, to store data in the persistent memory area.
As the KASLR offset is only needed by the tracer, that data is moved
from the ring buffer meta data into this new storage.
Next the modules that are loaded and where they are loaded is stored in this
new persistent storage.
The module list along with the KASLR offset is now exposed in the
last_boot_info if the buffer is from a previous boot. If it is from the
current boot, the file will only contain:
# Current
in order to not leak the KASLR offset.
Finally, when new modules are loaded while the trace is active, they too
will be added to this persistent memory. Note, if tracing is stopped, and
then restarted, it clears the module list and will reload all the modules
again so that it doesn't need to keep track of what is loaded or unloaded
while no tracing is going on.
Changse since v3: https://lore.kernel.org/linux-trace-kernel/20250304012516.282694507@goodmis.org/
- Added kerneldoc for scratch_size parameter for __ring_buffer_alloc_range()
Changes since v2: https://lore.kernel.org/linux-trace-kernel/20250215034301.624019422@goodmis.org/
- Have the module loop be protected by RCU and not preemption disabling
- Take the scratch_mutex outside of save_mod() to prevent deadlocks
Changes since v1: https://lore.kernel.org/all/20250205225031.799739376@goodmis.org/
- Rebased on top of the urgent branch
- Allow the size of the scratch area in the persistent ring buffer to be
defined by the caller.
- Change the output of the last_boot_info to show the kaslr instead of:
"Offset: <offset>" to "<offset>\t[kernel]" to make it consistent with
the module output.
Steven Rostedt (8):
ring-buffer: Use kaslr address instead of text delta
ring-buffer: Add buffer meta data for persistent ring buffer
ring-buffer: Add ring_buffer_meta_scratch()
tracing: Have persistent trace instances save KASLR offset
module: Add module_for_each_mod() function
tracing: Have persistent trace instances save module addresses
tracing: Show module names and addresses of last boot
tracing: Update modules to persistent instances when loaded
----
include/linux/module.h | 6 +
include/linux/ring_buffer.h | 8 +-
kernel/module/main.c | 13 +++
kernel/trace/ring_buffer.c | 246 ++++++++++++++++++++++++-----------------
kernel/trace/trace.c | 264 ++++++++++++++++++++++++++++++++++++++++----
kernel/trace/trace.h | 15 ++-
kernel/trace/trace_events.c | 40 +++++--
7 files changed, 449 insertions(+), 143 deletions(-)
WARNING: multiple messages have this Message-ID (diff)
From: Biju Das <biju.das.jz@bp.renesas.com>
To: rostedt@goodmis.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
Cc: akpm@linux-foundation.org, mark.rutland@arm.com,
mathieu.desnoyers@efficios.com, mhiramat@kernel.org,
biju.das.jz@bp.renesas.com
Subject: [PATCH v4 0/8] ring-buffer/tracing: Save module information in persistent memory
Date: Fri, 14 Mar 2025 09:59:04 +0000 [thread overview]
Message-ID: <20250305164539.379008535@goodmis.org> (raw) (raw)
Message-ID: <20250314095904.hMaUc3cXhr61SvDz_MN3Az8hojWmC8zsKuFudYNTIIw@z> (raw)
In-Reply-To: <20250305164539.379008535@goodmis.org>
From: Steven Rostedt <rostedt@goodmis.org>
> This updates the persistent instance to record what modules were
> loaded and what addresses they were loaded at.
This series is giving build error on linux-next for 2 days(next-20250314
and next-20250313) on Renesas RZ/G3E SMARC EVK platform (ARM64)
Reverting trace related commits fixes the build issue.
build-errors:
kernel/trace/trace.c: In function ‘save_mod’:
kernel/trace/trace.c:6041:45: error: invalid use of undefined type ‘struct module’
6041 | entry->mod_addr = (unsigned long)mod->mem[MOD_TEXT].base;
| ^~
CC net/ethtool/phc_vclocks.o
kernel/trace/trace.c:6041:51: error: ‘MOD_TEXT’ undeclared (first use in this function)
6041 | entry->mod_addr = (unsigned long)mod->mem[MOD_TEXT].base;
| ^~~~~~~~
kernel/trace/trace.c:6041:51: note: each undeclared identifier is reported only once for each function it appears in
CC fs/proc/cpuinfo.o
next reply other threads:[~2025-03-05 16:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 16:45 Steven Rostedt [this message]
2025-03-05 16:45 ` [PATCH v4 1/8] ring-buffer: Use kaslr address instead of text delta Steven Rostedt
2025-03-05 16:45 ` [PATCH v4 2/8] ring-buffer: Add buffer meta data for persistent ring buffer Steven Rostedt
2025-03-05 16:45 ` [PATCH v4 3/8] ring-buffer: Add ring_buffer_meta_scratch() Steven Rostedt
2025-03-05 16:45 ` [PATCH v4 4/8] tracing: Have persistent trace instances save KASLR offset Steven Rostedt
2025-03-05 16:45 ` [PATCH v4 5/8] module: Add module_for_each_mod() function Steven Rostedt
2025-03-05 16:45 ` [PATCH v4 6/8] tracing: Have persistent trace instances save module addresses Steven Rostedt
2025-03-05 16:45 ` [PATCH v4 7/8] tracing: Show module names and addresses of last boot Steven Rostedt
2025-03-05 16:45 ` [PATCH v4 8/8] tracing: Update modules to persistent instances when loaded Steven Rostedt
2025-03-14 9:53 ` Biju Das
2025-03-14 9:59 ` [PATCH v4 0/8] ring-buffer/tracing: Save module information in persistent memory Biju Das
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=20250305164539.379008535@goodmis.org \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--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 \
/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).