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/5] tracing: Fixes for 7.0
Date: Sat, 21 Mar 2026 23:09:54 -0400 [thread overview]
Message-ID: <20260322030954.198361547@kernel.org> (raw)
tracing fixes for 7.0:
- Revert "tracing: Remove pid in task_rename tracing output"
A change was made to remove the pid field from the task_rename event
because it was thought that it was always done for the current task and
recording the pid would be redundant. This turned out to be incorrect and
there are a few corner casse where this is not true and caused some
regressions in tooling.
- Fix the reading from user space for migration
The reading of user space uses a seq lock type of logic where it uses a
per-cpu temporary buffer and disables migration, then enables preemption,
does the copy from user space, disables preemption, enables migration and
checks if there was any schedule switches while preemption was enabled. If
there was a context switch, then it is considered that the per-cpu buffer
could be corrupted and it tries again. There's a protection check that
tests if it takes a hundred tries it issues a warning and exits out to
prevent a live lock.
This was triggered because the task was selected by the load balancer to
be migrated to another CPU, every time preemption is enabled the migration
task would schedule in try to migrate the task but can't because migration
is enabled and let it run again. This caused the scheduler to schedule out
the task every time it enabled preemption and made the loop never exit
(until the 100 iteration test triggered).
Fix this by enabling and disabling preemption and keeping migration
enabled on a failure. This will let the migration thread to migrate the
task and the copy from user space will likely pass on the next iteration.
- Fix trace_marker copy option freeing
The "copy_trace_marker" option allows an tracing instance to get a copy of
a write to the trace_marker file of the top level instance. This is
managed by a link list protected by RCU. When an instance is removed, a
check is made if the option is set, and if so synchronized_rcu() is
called. The problem is that an iteration is made to reset all the flags to
what they were when the instance was created (to perform clean ups) was
done before the check of the copy_trace_marker option and that option was
cleared, so the synchronize_rcu() was never called.
Move the clearing of all the flags after the check of copy_trace_marker to
do synchronize_rcu() so that the option is still set if it was before and
the synchronization is performed.
- Fix entries setting when validating the persistent ring buffer
When validating the persistent ring buffer on boot up, the number of
events per sub-buffer is added to the sub-buffer meta page. The validator
was updating cpu_buffer->head_page (the first sub-buffer of the per-cpu
buffer) and not the "head_page" variable that was iterating the
sub-buffers. This was causing the first sub-buffer to be assigned the
entries for each sub-buffer and not the sub-buffer that was supposed to be
updated.
- Use "hash" value to update the direct callers
When updating the ftrace direct direct callers it assigned a temporary
callback to all the callback functions of the ftrace ops and not just the
functions represented by the passed in hash. This causes an unnecessary
slow down of the functions of the ftrace_ops that is not being modified.
Only update the functions that are going to be modified to call the ftrace
loop function so that the update can be made on those functions.
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace/fixes
Head SHA1: 50b35c9e50a865600344ab1d8f9a8b3384d7e63d
Jiri Olsa (1):
ftrace: Use hash argument for tmp_ops in update_ftrace_direct_mod
Masami Hiramatsu (Google) (1):
ring-buffer: Fix to update per-subbuf entries of persistent ring buffer
Steven Rostedt (2):
tracing: Fix failure to read user space from system call trace events
tracing: Fix trace_marker copy link list updates
Xuewen Yan (1):
tracing: Revert "tracing: Remove pid in task_rename tracing output"
----
include/trace/events/task.h | 7 +++++--
kernel/trace/ftrace.c | 4 ++--
kernel/trace/ring_buffer.c | 2 +-
kernel/trace/trace.c | 36 +++++++++++++++++++++++++++---------
4 files changed, 35 insertions(+), 14 deletions(-)
next reply other threads:[~2026-03-22 3:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-22 3:09 Steven Rostedt [this message]
2026-03-22 3:09 ` [for-linus][PATCH 1/5] tracing: Revert "tracing: Remove pid in task_rename tracing output" Steven Rostedt
2026-03-22 3:09 ` [for-linus][PATCH 2/5] tracing: Fix failure to read user space from system call trace events Steven Rostedt
2026-03-22 3:09 ` [for-linus][PATCH 3/5] tracing: Fix trace_marker copy link list updates Steven Rostedt
2026-03-22 3:09 ` [for-linus][PATCH 4/5] ring-buffer: Fix to update per-subbuf entries of persistent ring buffer Steven Rostedt
2026-03-22 3:09 ` [for-linus][PATCH 5/5] ftrace: Use hash argument for tmp_ops in update_ftrace_direct_mod Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2026-02-19 20:49 [for-linus][PATCH 0/5] tracing: Fixes for 7.0 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=20260322030954.198361547@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