From: Steven Rostedt <rostedt@kernel.org>
To: linux-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: [for-linus][PATCH 0/4] tracing: One crash fix and 3 minor fixes for v6.19
Date: Sat, 24 Jan 2026 11:29:43 -0500 [thread overview]
Message-ID: <20260124162943.928691049@kernel.org> (raw)
tracing fixes for v6.19:
- Fix a crash with passing a stacktrace between synthetic events
A synthetic event is an event that combines two events into a single event
that can display fields from both events as well as the time delta that
took place between the events. It can also pass a stacktrace from the
first event so that it can be displayed by the synthetic event (this is
useful to get a stacktrace of a task scheduling out when blocked and
recording the time it was blocked for).
A synthetic event can also connect an existing synthetic event to another
event. An issue was found that if the first synthetic event had a stacktrace
as one of its fields, and that stacktrace field was passed to the new
synthetic event to be displayed, it would crash the kernel. This was due to
the stacktrace not being saved as a stacktrace but was still marked as one.
When the stacktrace was read, it would try to read an array but instead read
the integer metadata of the stacktrace and dereferenced a bad value.
Fix this by saving the stacktrace field as a stracktrace.
- Fix possible overflow in cmp_mod_entry() compare function
A binary search is used to find a module address and if the addresses are
greater than 2GB apart it could lead to truncation and cause a bad search
result. Use normal compares instead of a subtraction between addresses to
calculate the compare value.
- Fix output of entry arguments in function graph tracer
Depending on the configurations enabled, the entry can be two different
types that hold the argument array. The macro FGRAPH_ENTRY_ARGS() is used
to find the correct arguments from the given type. One location was missed
and still referenced the arguments directly via entry->args and could
produce the wrong value depending on how the kernel was configured.
- Fix memory leak in scripts/tracepoint-update build tool
If the array fails to allocate, the memory for the values needs to be
freed and was not. Free the allocated values if the array failed to
allocate.
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace/fixes
Head SHA1: 361eb853c655288f3b5c8020f6cd95d69ffe6479
Donglin Peng (1):
function_graph: Fix args pointer mismatch in print_graph_retval()
Ian Rogers (1):
tracing: Avoid possible signed 64-bit truncation
Steven Rostedt (1):
tracing: Fix crash on synthetic stacktrace field usage
Weigang He (1):
scripts/tracepoint-update: Fix memory leak in add_string() on failure
----
kernel/trace/trace.c | 8 ++++----
kernel/trace/trace_events_hist.c | 9 +++++++++
kernel/trace/trace_events_synth.c | 8 +++++++-
kernel/trace/trace_functions_graph.c | 2 +-
scripts/tracepoint-update.c | 2 ++
5 files changed, 23 insertions(+), 6 deletions(-)
next reply other threads:[~2026-01-24 16:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-24 16:29 Steven Rostedt [this message]
2026-01-24 16:29 ` [for-linus][PATCH 1/4] tracing: Fix crash on synthetic stacktrace field usage Steven Rostedt
2026-01-24 16:29 ` [for-linus][PATCH 2/4] tracing: Avoid possible signed 64-bit truncation Steven Rostedt
2026-01-24 16:29 ` [for-linus][PATCH 3/4] function_graph: Fix args pointer mismatch in print_graph_retval() Steven Rostedt
2026-01-24 16:29 ` [for-linus][PATCH 4/4] scripts/tracepoint-update: Fix memory leak in add_string() on failure 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=20260124162943.928691049@kernel.org \
--to=rostedt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-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