* [for-linus][PATCH 1/3] ring-buffer: Do not warn in ring_buffer_map_get_reader() when reader catches up
2025-11-07 13:07 [for-linus][PATCH 0/3] tracing: Fixes for v6.18 Steven Rostedt
@ 2025-11-07 13:07 ` Steven Rostedt
2025-11-07 13:07 ` [for-linus][PATCH 2/3] tracing: Fix memory leaks in create_field_var() Steven Rostedt
2025-11-07 13:07 ` [for-linus][PATCH 3/3] tracing/tools: Fix incorrcet short option in usage text for --threads Steven Rostedt
2 siblings, 0 replies; 6+ messages in thread
From: Steven Rostedt @ 2025-11-07 13:07 UTC (permalink / raw)
To: linux-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Tomas Glozar, John Kacur, stable, Vincent Donnefort,
syzbot+92a3745cea5ec6360309
From: Steven Rostedt <rostedt@goodmis.org>
The function ring_buffer_map_get_reader() is a bit more strict than the
other get reader functions, and except for certain situations the
rb_get_reader_page() should not return NULL. If it does, it triggers a
warning.
This warning was triggering but after looking at why, it was because
another acceptable situation was happening and it wasn't checked for.
If the reader catches up to the writer and there's still data to be read
on the reader page, then the rb_get_reader_page() will return NULL as
there's no new page to get.
In this situation, the reader page should not be updated and no warning
should trigger.
Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Vincent Donnefort <vdonnefort@google.com>
Reported-by: syzbot+92a3745cea5ec6360309@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/690babec.050a0220.baf87.0064.GAE@google.com/
Link: https://lore.kernel.org/20251016132848.1b11bb37@gandalf.local.home
Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functions")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
kernel/trace/ring_buffer.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 1244d2c5c384..afcd3747264d 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -7344,6 +7344,10 @@ int ring_buffer_map_get_reader(struct trace_buffer *buffer, int cpu)
goto out;
}
+ /* Did the reader catch up with the writer? */
+ if (cpu_buffer->reader_page == cpu_buffer->commit_page)
+ goto out;
+
reader = rb_get_reader_page(cpu_buffer);
if (WARN_ON(!reader))
goto out;
--
2.51.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [for-linus][PATCH 2/3] tracing: Fix memory leaks in create_field_var()
2025-11-07 13:07 [for-linus][PATCH 0/3] tracing: Fixes for v6.18 Steven Rostedt
2025-11-07 13:07 ` [for-linus][PATCH 1/3] ring-buffer: Do not warn in ring_buffer_map_get_reader() when reader catches up Steven Rostedt
@ 2025-11-07 13:07 ` Steven Rostedt
2025-11-07 13:07 ` [for-linus][PATCH 3/3] tracing/tools: Fix incorrcet short option in usage text for --threads Steven Rostedt
2 siblings, 0 replies; 6+ messages in thread
From: Steven Rostedt @ 2025-11-07 13:07 UTC (permalink / raw)
To: linux-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Tomas Glozar, John Kacur, Zilin Guan
From: Zilin Guan <zilin@seu.edu.cn>
The function create_field_var() allocates memory for 'val' through
create_hist_field() inside parse_atom(), and for 'var' through
create_var(), which in turn allocates var->type and var->var.name
internally. Simply calling kfree() to release these structures will
result in memory leaks.
Use destroy_hist_field() to properly free 'val', and explicitly release
the memory of var->type and var->var.name before freeing 'var' itself.
Link: https://patch.msgid.link/20251106120132.3639920-1-zilin@seu.edu.cn
Fixes: 02205a6752f22 ("tracing: Add support for 'field variables'")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
kernel/trace/trace_events_hist.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 1d536219b624..6bfaf1210dd2 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -3272,14 +3272,16 @@ static struct field_var *create_field_var(struct hist_trigger_data *hist_data,
var = create_var(hist_data, file, field_name, val->size, val->type);
if (IS_ERR(var)) {
hist_err(tr, HIST_ERR_VAR_CREATE_FIND_FAIL, errpos(field_name));
- kfree(val);
+ destroy_hist_field(val, 0);
ret = PTR_ERR(var);
goto err;
}
field_var = kzalloc(sizeof(struct field_var), GFP_KERNEL);
if (!field_var) {
- kfree(val);
+ destroy_hist_field(val, 0);
+ kfree_const(var->type);
+ kfree(var->var.name);
kfree(var);
ret = -ENOMEM;
goto err;
--
2.51.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [for-linus][PATCH 3/3] tracing/tools: Fix incorrcet short option in usage text for --threads
2025-11-07 13:07 [for-linus][PATCH 0/3] tracing: Fixes for v6.18 Steven Rostedt
2025-11-07 13:07 ` [for-linus][PATCH 1/3] ring-buffer: Do not warn in ring_buffer_map_get_reader() when reader catches up Steven Rostedt
2025-11-07 13:07 ` [for-linus][PATCH 2/3] tracing: Fix memory leaks in create_field_var() Steven Rostedt
@ 2025-11-07 13:07 ` Steven Rostedt
2025-11-07 13:37 ` Mathieu Desnoyers
2 siblings, 1 reply; 6+ messages in thread
From: Steven Rostedt @ 2025-11-07 13:07 UTC (permalink / raw)
To: linux-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Tomas Glozar, John Kacur, Zhang Chujun
From: Zhang Chujun <zhangchujun@cmss.chinamobile.com>
The help message incorrectly listed '-t' as the short option for
--threads, but the actual getopt_long configuration uses '-e'.
This mismatch can confuse users and lead to incorrect command-line
usage. This patch updates the usage string to correctly show:
"-e, --threads NRTHR"
to match the implementation.
Note: checkpatch.pl reports a false-positive spelling warning on
'Run', which is intentional.
Link: https://patch.msgid.link/20251106031040.1869-1-zhangchujun@cmss.chinamobile.com
Signed-off-by: Zhang Chujun <zhangchujun@cmss.chinamobile.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
tools/tracing/latency/latency-collector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/tracing/latency/latency-collector.c b/tools/tracing/latency/latency-collector.c
index cf263fe9deaf..ef97916e3873 100644
--- a/tools/tracing/latency/latency-collector.c
+++ b/tools/tracing/latency/latency-collector.c
@@ -1725,7 +1725,7 @@ static void show_usage(void)
"-n, --notrace\t\tIf latency is detected, do not print out the content of\n"
"\t\t\tthe trace file to standard output\n\n"
-"-t, --threads NRTHR\tRun NRTHR threads for printing. Default is %d.\n\n"
+"-e, --threads NRTHR\tRun NRTHR threads for printing. Default is %d.\n\n"
"-r, --random\t\tArbitrarily sleep a certain amount of time, default\n"
"\t\t\t%ld ms, before reading the trace file. The\n"
--
2.51.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [for-linus][PATCH 3/3] tracing/tools: Fix incorrcet short option in usage text for --threads
2025-11-07 13:07 ` [for-linus][PATCH 3/3] tracing/tools: Fix incorrcet short option in usage text for --threads Steven Rostedt
@ 2025-11-07 13:37 ` Mathieu Desnoyers
2025-11-07 17:36 ` Steven Rostedt
0 siblings, 1 reply; 6+ messages in thread
From: Mathieu Desnoyers @ 2025-11-07 13:37 UTC (permalink / raw)
To: Steven Rostedt, linux-kernel
Cc: Masami Hiramatsu, Mark Rutland, Andrew Morton, Tomas Glozar,
John Kacur, Zhang Chujun
On 2025-11-07 08:07, Steven Rostedt wrote:
Nit: Subject: incorrcet -> incorrect
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [for-linus][PATCH 3/3] tracing/tools: Fix incorrcet short option in usage text for --threads
2025-11-07 13:37 ` Mathieu Desnoyers
@ 2025-11-07 17:36 ` Steven Rostedt
0 siblings, 0 replies; 6+ messages in thread
From: Steven Rostedt @ 2025-11-07 17:36 UTC (permalink / raw)
To: Mathieu Desnoyers, Steven Rostedt, linux-kernel
Cc: Masami Hiramatsu, Mark Rutland, Andrew Morton, Tomas Glozar,
John Kacur, Zhang Chujun
On November 7, 2025 8:37:13 AM EST, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
>On 2025-11-07 08:07, Steven Rostedt wrote:
>
>Nit: Subject: incorrcet -> incorrect
I saw that just as I did the pull request but figured it wasn't big enough to stop the request.
-- Steve
>
>Thanks,
>
>Mathieu
>
^ permalink raw reply [flat|nested] 6+ messages in thread