Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1693338 > unrolled thread

Re: [PATCH 18/32] tracing: Add simple expression support to hist triggers

Started byNamhyung Kim <namhyung@kernel.org>
First post2017-07-21 04:10 +0200
Last post2017-07-21 18:30 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 18/32] tracing: Add simple expression support to hist  triggers Namhyung Kim <namhyung@kernel.org> - 2017-07-21 04:10 +0200
    Re: [PATCH 18/32] tracing: Add simple expression support to hist  triggers Tom Zanussi <tom.zanussi@linux.intel.com> - 2017-07-21 18:30 +0200

#1693338 — Re: [PATCH 18/32] tracing: Add simple expression support to hist triggers

FromNamhyung Kim <namhyung@kernel.org>
Date2017-07-21 04:10 +0200
SubjectRe: [PATCH 18/32] tracing: Add simple expression support to hist triggers
Message-ID<u5vya-7aa-13@gated-at.bofh.it>
Hi Tom,

On Mon, Jun 26, 2017 at 05:49:19PM -0500, Tom Zanussi wrote:
> Add support for simple addition, subtraction, and unary expressions
> (-(expr) and expr, where expr = b-a, a+b, a+b+c) to hist triggers, in
> order to support a minimal set of useful inter-event calculations.
> 
> These operations are needed for calculating latencies between events
> (timestamp1-timestamp0) and for combined latencies (latencies over 3
> or more events).
> 
> In the process, factor out some common code from key and value
> parsing.
> 
> Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
> ---

[SNIP]
> +static char *expr_str(struct hist_field *field, unsigned int level)
> +{
> +	char *expr = kzalloc(MAX_FILTER_STR_VAL, GFP_KERNEL);
> +
> +	if (!expr || level > 1)
> +		return NULL;

Looks like a memory leak.


[SNIP]
> +static struct hist_field *parse_expr(struct hist_trigger_data *hist_data,
> +				     struct trace_event_file *file,
> +				     char *str, unsigned long flags,
> +				     char *var_name, unsigned int level)
> +{
> +	struct hist_field *operand1 = NULL, *operand2 = NULL, *expr = NULL;
> +	unsigned long operand_flags;
> +	int field_op, ret = -EINVAL;
> +	char *sep, *operand1_str;
> +
> +	if (level > 2)
> +		return NULL;
> +
> +	field_op = contains_operator(str);
> +	if (field_op == FIELD_OP_NONE)
> +		return NULL;

Why not calling parse_atom() here?  It'd make the code simpler IMHO.

Thanks,
Namhyung


> +
> +	if (field_op == FIELD_OP_UNARY_MINUS)
> +		return parse_unary(hist_data, file, str, flags, var_name, ++level);
> +
> +	switch (field_op) {
> +	case FIELD_OP_MINUS:
> +		sep = "-";
> +		break;
> +	case FIELD_OP_PLUS:
> +		sep = "+";
> +		break;
> +	default:
> +		goto free;
> +	}
> +
> +	operand1_str = strsep(&str, sep);
> +	if (!operand1_str || !str)
> +		goto free;
> +
> +	operand_flags = 0;
> +	operand1 = parse_atom(hist_data, file, operand1_str,
> +			      &operand_flags, NULL);
> +	if (IS_ERR(operand1)) {
> +		ret = PTR_ERR(operand1);
> +		operand1 = NULL;
> +		goto free;
> +	}
> +
> +	// rest of string could be another expression e.g. b+c in a+b+c
> +	operand_flags = 0;
> +	operand2 = parse_expr(hist_data, file, str, operand_flags, NULL, ++level);
> +	if (IS_ERR(operand2)) {
> +		ret = PTR_ERR(operand2);
> +		operand2 = NULL;
> +		goto free;
> +	}
> +	if (!operand2) {
> +		operand_flags = 0;
> +		operand2 = parse_atom(hist_data, file, str,
> +				      &operand_flags, NULL);
> +		if (IS_ERR(operand2)) {
> +			ret = PTR_ERR(operand2);
> +			operand2 = NULL;
> +			goto free;
> +		}
> +	}
> +
> +	flags |= HIST_FIELD_FL_EXPR;
> +	expr = create_hist_field(hist_data, NULL, flags, var_name);
> +	if (!expr) {
> +		ret = -ENOMEM;
> +		goto free;
> +	}
> +
> +	expr->operands[0] = operand1;
> +	expr->operands[1] = operand2;
> +	expr->operator = field_op;
> +	expr->name = expr_str(expr, 0);
> +
> +	switch (field_op) {
> +	case FIELD_OP_MINUS:
> +		expr->fn = hist_field_minus;
> +		break;
> +	case FIELD_OP_PLUS:
> +		expr->fn = hist_field_plus;
> +		break;
> +	default:
> +		goto free;
> +	}
> +
> +	return expr;
> + free:
> +	destroy_hist_field(operand1, 0);
> +	destroy_hist_field(operand2, 0);
> +	destroy_hist_field(expr, 0);
> +
> +	return ERR_PTR(ret);
> +}

[toc] | [next] | [standalone]


#1693837

FromTom Zanussi <tom.zanussi@linux.intel.com>
Date2017-07-21 18:30 +0200
Message-ID<u5IYp-788-17@gated-at.bofh.it>
In reply to#1693338
Hi Namhyung,

On Fri, 2017-07-21 at 11:02 +0900, Namhyung Kim wrote:
> Hi Tom,
> 
> On Mon, Jun 26, 2017 at 05:49:19PM -0500, Tom Zanussi wrote:
> > Add support for simple addition, subtraction, and unary expressions
> > (-(expr) and expr, where expr = b-a, a+b, a+b+c) to hist triggers, in
> > order to support a minimal set of useful inter-event calculations.
> > 
> > These operations are needed for calculating latencies between events
> > (timestamp1-timestamp0) and for combined latencies (latencies over 3
> > or more events).
> > 
> > In the process, factor out some common code from key and value
> > parsing.
> > 
> > Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
> > ---
> 
> [SNIP]
> > +static char *expr_str(struct hist_field *field, unsigned int level)
> > +{
> > +	char *expr = kzalloc(MAX_FILTER_STR_VAL, GFP_KERNEL);
> > +
> > +	if (!expr || level > 1)
> > +		return NULL;
> 
> Looks like a memory leak.
> 
> 

Indeed, and so obvious I can't believe I missed it.  Thanks for pointing
it out.

> [SNIP]
> > +static struct hist_field *parse_expr(struct hist_trigger_data *hist_data,
> > +				     struct trace_event_file *file,
> > +				     char *str, unsigned long flags,
> > +				     char *var_name, unsigned int level)
> > +{
> > +	struct hist_field *operand1 = NULL, *operand2 = NULL, *expr = NULL;
> > +	unsigned long operand_flags;
> > +	int field_op, ret = -EINVAL;
> > +	char *sep, *operand1_str;
> > +
> > +	if (level > 2)
> > +		return NULL;
> > +
> > +	field_op = contains_operator(str);
> > +	if (field_op == FIELD_OP_NONE)
> > +		return NULL;
> 
> Why not calling parse_atom() here?  It'd make the code simpler IMHO.
> 

Yeah, I think that would be much nicer, will do.

Thanks,

Tom

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web