Messages in this thread Patch in this message | | | Date | Sun, 25 Jul 2021 12:45:02 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH v2 2/2] tracing: Allow execnames to be passed as args for synthetic events |
| |
On Sun, 25 Jul 2021 11:18:30 +0900 Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Hi, > > On Sat, 24 Jul 2021 19:31:45 +0900 > Masami Hiramatsu <mhiramat@kernel.org> wrote: > > > Hi Steve, > > > > On Thu, 22 Jul 2021 21:24:38 -0400 > > Steven Rostedt <rostedt@goodmis.org> wrote: > > > > > On Fri, 23 Jul 2021 10:11:33 +0900 > > > Masami Hiramatsu <mhiramat@kernel.org> wrote: > > > > > > > I understand. As far as I can see the code, it looks a bit complicated. > > > > To simplify it, I need to understand the spec for "hist_field" > > > > for keys and for vars. And maybe need to split both case. > > > > > > I'll give you a hint that took me a bit to figure out. > > > > > > 1) The execname is saved at the start of the histogram and not by one > > > of the ->fn() functions. > > > > > > It's saved by hist_trigger_elt_data_init() if the elt_data->comm is > > > allocated. That function is part of the "tracing_map_ops" which gets > > > assigned by tracing_map_create() (in tracing_map.c) as the "elt_init" > > > function, which is called when getting a new elt element by > > > get_free_elt(). > > > > > > 2) That elt_data->comm is only allocated if it finds a "hist_field" > > > that has HIST_FIELD_FL_EXECNAME flag set. It currently only looks for > > > that flag in the "keys" fields, which means that .execname is useless > > > for everything else. This patch changed it to search all hist_fields so > > > that it can find that flag if a variable has it set (which I added). > > > > Thanks for the hints, but actually, that part looks good to me. > > > > So, what I pointed was the part of update_var_execname(). Below diff > > is what I intended. > > This moves HIST_FIELD_FL_EXECNAME setup in the create_hist_field() > > as same as other flags, and removed the add-hoc update_var_execname() > > fixup function. > > > > I confirmed it passed the ftracetest trigger testcases and your > > example code. > > > > Thank you, > > > > I found a bug in this change. > > [..] > > @@ -1682,6 +1703,16 @@ static struct hist_field *create_hist_field(struct hist_trigger_data *hist_data, > > goto out; > > } > > > > + if ((flags & HIST_FIELD_FL_EXECNAME) && var_name) { > > + flags |= HIST_FIELD_FL_STRING | HIST_FIELD_FL_VAR; > > Here, we don't need to check 'var_name' and remove HIST_FIELD_FL_VAR, since it must be set in the flag. > > if (flags & HIST_FIELD_FL_EXECNAME) { > flags |= HIST_FIELD_FL_STRING;
And with this change, hist trigger can correctly detect a string type in the operand in the expression and rejects it.
Thank you,
From 5280d1efe4415a621cf69a1dc4861ab928b0ff1c Mon Sep 17 00:00:00 2001 From: Masami Hiramatsu <mhiramat@kernel.org> Date: Sun, 25 Jul 2021 12:34:00 +0900 Subject: [PATCH] tracing: Reject string operand in the histogram expression
Since the string type can not be the target of the addition / subtraction operation, it must be rejected. Without this fix, the string type silently converted to digits.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> --- kernel/trace/trace_events_hist.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index 76e3100a4840..3eea60e2da48 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -65,7 +65,8 @@ C(INVALID_SORT_MODIFIER,"Invalid sort modifier"), \ C(EMPTY_SORT_FIELD, "Empty sort field"), \ C(TOO_MANY_SORT_FIELDS, "Too many sort fields (Max = 2)"), \ - C(INVALID_SORT_FIELD, "Sort field must be a key or a val"), + C(INVALID_SORT_FIELD, "Sort field must be a key or a val"), \ + C(INVALID_STR_OPERAND, "String type can not be an operand in expression"), #undef C #define C(a, b) HIST_ERR_##a @@ -2183,6 +2184,13 @@ static struct hist_field *parse_unary(struct hist_trigger_data *hist_data, ret = PTR_ERR(operand1); goto free; } + if (operand1->flags & HIST_FIELD_FL_STRING) { + /* String type can not be the operand of unary operator. */ + hist_err(file->tr, HIST_ERR_INVALID_STR_OPERAND, errpos(str)); + destroy_hist_field(operand1, 0); + ret = -EINVAL; + goto free; + } expr->flags |= operand1->flags & (HIST_FIELD_FL_TIMESTAMP | HIST_FIELD_FL_TIMESTAMP_USECS); @@ -2284,6 +2292,11 @@ static struct hist_field *parse_expr(struct hist_trigger_data *hist_data, operand1 = NULL; goto free; } + if (operand1->flags & HIST_FIELD_FL_STRING) { + hist_err(file->tr, HIST_ERR_INVALID_STR_OPERAND, errpos(operand1_str)); + ret = -EINVAL; + goto free; + } /* rest of string could be another expression e.g. b+c in a+b+c */ operand_flags = 0; @@ -2293,6 +2306,11 @@ static struct hist_field *parse_expr(struct hist_trigger_data *hist_data, operand2 = NULL; goto free; } + if (operand2->flags & HIST_FIELD_FL_STRING) { + hist_err(file->tr, HIST_ERR_INVALID_STR_OPERAND, errpos(str)); + ret = -EINVAL; + goto free; + } ret = check_expr_operands(file->tr, operand1, operand2); if (ret) -- 2.25.1
-- Masami Hiramatsu <mhiramat@kernel.org>
| |