lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171121105325.GA17299@sejong>
Date:   Tue, 21 Nov 2017 19:53:25 +0900
From:   Namhyung Kim <namhyung@...nel.org>
To:     Tom Zanussi <tom.zanussi@...ux.intel.com>
Cc:     rostedt@...dmis.org, tglx@...utronix.de, mhiramat@...nel.org,
        vedang.patel@...el.com, bigeasy@...utronix.de,
        joel.opensrc@...il.com, joelaf@...gle.com,
        mathieu.desnoyers@...icios.com, baohong.liu@...el.com,
        rajvi.jingar@...el.com, julia@...com, fengguang.wu@...el.com,
        linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
        kernel-team@....com
Subject: Re: [PATCH v6 22/37] tracing: Add variable reference handling to
 hist triggers

On Fri, Nov 17, 2017 at 02:33:01PM -0600, Tom Zanussi wrote:
> Add the necessary infrastructure to allow the variables defined on one
> event to be referenced in another.  This allows variables set by a
> previous event to be referenced and used in expressions combining the
> variable values saved by that previous event and the event fields of
> the current event.  For example, here's how a latency can be
> calculated and saved into yet another variable named 'wakeup_lat':
> 
>     # echo 'hist:keys=pid,prio:ts0=$common_timestamp ...
>     # echo 'hist:keys=next_pid:wakeup_lat=$common_timestamp-$ts0 ...
> 
> In the first event, the event's timetamp is saved into the variable
> ts0.  In the next line, ts0 is subtracted from the second event's
> timestamp to produce the latency.
> 
> Further users of variable references will be described in subsequent
> patches, such as for instance how the 'wakeup_lat' variable above can
> be displayed in a latency histogram.
> 
> Signed-off-by: Tom Zanussi <tom.zanussi@...ux.intel.com>
> ---

[SNIP]
> @@ -914,13 +1383,38 @@ struct hist_field *parse_atom(struct hist_trigger_data *hist_data,
>  			      struct trace_event_file *file, char *str,
>  			      unsigned long *flags, char *var_name)
>  {
> -	char *s;
> +	char *s, *ref_system = NULL, *ref_event = NULL, *ref_var = str;
>  	struct ftrace_event_field *field = NULL;
>  	struct hist_field *hist_field = NULL;
>  	int ret = 0;
>  
> -	s = local_field_var_ref(hist_data, str);
> -	if (s)
> +	s = strchr(str, '.');
> +	if (s) {
> +		s = strchr(++s, '.');
> +		if (s) {
> +			ref_system = strsep(&str, ".");
> +			if (!str) {
> +				ret = -EINVAL;
> +				goto out;
> +			}
> +			ref_event = strsep(&str, ".");
> +			if (!str) {
> +				ret = -EINVAL;
> +				goto out;
> +			}
> +			ref_var = str;
> +		}
> +	}
> +
> +	s = local_field_var_ref(hist_data, ref_var);

Wouldn't it be called when ref_system + ref_event are NULL or same as
hist_data->file's ?

Thanks,
Namhyung


> +	if (!s) {
> +		hist_field = parse_var_ref(hist_data, ref_system, ref_event, ref_var);
> +		if (hist_field) {
> +			hist_data->var_refs[hist_data->n_var_refs] = hist_field;
> +			hist_field->var_ref_idx = hist_data->n_var_refs++;
> +			return hist_field;
> +		}
> +	} else
>  		str = s;
>  
>  	field = parse_field(hist_data, file, str, flags);

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ