From: Steven Rostedt <rostedt@goodmis.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: Fixes for v6.15
Date: Wed, 14 May 2025 09:38:31 -0400 [thread overview]
Message-ID: <20250514133831.110736154@goodmis.org> (raw)
tracing fixes for 6.15:
- Fix sample code that uses trace_array_printk()
The sample code for in kernel use of trace_array (that creates an instance
for use within the kernel) and shows how to use trace_array_printk() that
writes into the created instance, used trace_printk_init_buffers(). But
that function is used to initialize normal trace_printk() and produces the
NOTICE banner which is not needed for use of trace_array_printk(). The
function to initialize that is trace_array_init_printk() that takes the
created trace array instance as a parameter.
Update the sample code to reflect the proper usage.
- Fix preemption count output for stacktrace event
The tracing buffer shows the preempt count level when an event executes.
Because writing the event itself disables preemption, this needs to be
accounted for when recording. The stacktrace event did not account for
this so the output of the stacktrace event showed preemption was disabled
while the event that triggered the stacktrace shows preemption is enabled
and this leads to confusion. Account for preemption being disabled for the
stacktrace event.
The same happened for stack traces triggered by function tracer.
- Fix persistent ring buffer when trace_pipe is used
The ring buffer swaps the reader page with the next page to read from the
write buffer when trace_pipe is used. If there's only a page of data in
the ring buffer, this swap will cause the "commit" pointer (last data
written) to be on the reader page. If more data is written to the buffer,
it is added to the reader page until it falls off back into the write
buffer.
If the system reboots and the commit pointer is still on the reader page,
even if new data was written, the persistent buffer validator will miss
finding the commit pointer because it only checks the write buffer and
does not check the reader page. This causes the validator to fail the
validation and clear the buffer, where the new data is lost.
There was a check for this, but it checked the "head pointer", which was
incorrect, because the "head pointer" always stays on the write buffer and
is the next page to swap out for the reader page. Fix the logic to catch
this case and allow the user to still read the data after reboot.
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace/fixes
Head SHA1: 2285fb6d4d72a833d6e5ffbbe2f5ff594f0398cc
Steven Rostedt (2):
tracing: samples: Initialize trace_array_printk() with the correct function
ring-buffer: Fix persistent buffer when commit page is the reader page
pengdonglin (2):
ftrace: Fix preemption acounting for stacktrace trigger command
ftrace: Fix preemption accounting for stacktrace filter command
----
kernel/trace/ring_buffer.c | 8 +++++---
kernel/trace/trace_events_trigger.c | 2 +-
kernel/trace/trace_functions.c | 6 +-----
samples/ftrace/sample-trace-array.c | 2 +-
4 files changed, 8 insertions(+), 10 deletions(-)
next reply other threads:[~2025-05-14 13:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 13:38 Steven Rostedt [this message]
2025-05-14 13:38 ` [for-linus][PATCH 1/4] tracing: samples: Initialize trace_array_printk() with the correct function Steven Rostedt
2025-05-14 13:38 ` [for-linus][PATCH 2/4] ftrace: Fix preemption acounting for stacktrace trigger command Steven Rostedt
2025-05-14 13:38 ` [for-linus][PATCH 3/4] ftrace: Fix preemption accounting for stacktrace filter command Steven Rostedt
2025-05-14 13:38 ` [for-linus][PATCH 4/4] ring-buffer: Fix persistent buffer when commit page is the reader page Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2025-05-02 14:46 [for-linus][PATCH 0/4] tracing: Fixes for v6.15 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=20250514133831.110736154@goodmis.org \
--to=rostedt@goodmis.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