This is a note to let you know that I've just added the patch titled
tracing / histogram: Give calculation hist_fields a size
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
tracing-histogram-give-calculation-hist_fields-a-size.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 2c05caa7ba8803209769b9e4fe02c38d77ae88d0 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt@xxxxxxxxxxx>
Date: Fri, 30 Jul 2021 17:19:51 -0400
Subject: tracing / histogram: Give calculation hist_fields a size
From: Steven Rostedt (VMware) <rostedt@xxxxxxxxxxx>
commit 2c05caa7ba8803209769b9e4fe02c38d77ae88d0 upstream.
When working on my user space applications, I found a bug in the synthetic
event code where the automated synthetic event field was not matching the
event field calculation it was attached to. Looking deeper into it, it was
because the calculation hist_field was not given a size.
The synthetic event fields are matched to their hist_fields either by
having the field have an identical string type, or if that does not match,
then the size and signed values are used to match the fields.
The problem arose when I tried to match a calculation where the fields
were "unsigned int". My tool created a synthetic event of type "u32". But
it failed to match. The string was:
diff=field1-field2:onmatch(event).trace(synth,$diff)
Adding debugging into the kernel, I found that the size of "diff" was 0.
And since it was given "unsigned int" as a type, the histogram fallback
code used size and signed. The signed matched, but the size of u32 (4) did
not match zero, and the event failed to be created.
This can be worse if the field you want to match is not one of the
acceptable fields for a synthetic event. As event fields can have any type
that is supported in Linux, this can cause an issue. For example, if a
type is an enum. Then there's no way to use that with any calculations.
Have the calculation field simply take on the size of what it is
calculating.
Link: https://lkml.kernel.org/r/20210730171951.59c7743f@xxxxxxxxxxxxxxxx
Cc: Tom Zanussi <zanussi@xxxxxxxxxx>
Cc: Masami Hiramatsu <mhiramat@xxxxxxxxxx>
Cc: Namhyung Kim <namhyung@xxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
Fixes: 100719dcef447 ("tracing: Add simple expression support to hist triggers")
Signed-off-by: Steven Rostedt (VMware) <rostedt@xxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
kernel/trace/trace_events_hist.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -2271,6 +2271,10 @@ static struct hist_field *parse_expr(str
expr->operands[0] = operand1;
expr->operands[1] = operand2;
+
+ /* The operand sizes should be the same, so just pick one */
+ expr->size = operand1->size;
+
expr->operator = field_op;
expr->name = expr_str(expr, 0);
expr->type = kstrdup(operand1->type, GFP_KERNEL);
Patches currently in stable-queue which might be from rostedt@xxxxxxxxxxx are
queue-5.10/tracing-fix-null-pointer-dereference-in-start_creating.patch
queue-5.10/tracepoint-static-call-compare-data-on-transition-from-2-1-callees.patch
queue-5.10/tracing-histogram-give-calculation-hist_fields-a-size.patch
queue-5.10/tracepoint-fix-static-call-function-vs-data-state-mismatch.patch
queue-5.10/tracing-reject-string-operand-in-the-histogram-expression.patch
queue-5.10/scripts-tracing-fix-the-bug-that-can-t-parse-raw_trace_func.patch
