| 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
| ||
|
Message-ID: <20151103003437.GC11498@danjae.kornet>
Date: Tue, 3 Nov 2015 09:34:37 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Tom Zanussi <tom.zanussi@...ux.intel.com>
Cc: rostedt@...dmis.org, daniel.wagner@...-carit.de,
masami.hiramatsu.pt@...achi.com, josh@...htriplett.org,
andi@...stfloor.org, mathieu.desnoyers@...icios.com,
peterz@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v11 24/28] tracing: Add support for multiple hist
triggers per event
On Thu, Oct 22, 2015 at 01:14:28PM -0500, Tom Zanussi wrote:
> Allow users to define any number of hist triggers per trace event.
> Any number of hist triggers may be added for a given event, which may
> differ by key, value, or filter.
>
> Reading the event's 'hist' file will display the output of all the
> hist triggers defined on an event concatenated in the order they were
> defined.
>
> Signed-off-by: Tom Zanussi <tom.zanussi@...ux.intel.com>
> Tested-by: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
> ---
> Documentation/trace/events.txt | 151 +++++++++++++++++++++++++++++++++++++--
> kernel/trace/trace.c | 8 ++-
> kernel/trace/trace_events_hist.c | 138 ++++++++++++++++++++++++++---------
> 3 files changed, 256 insertions(+), 41 deletions(-)
>
> diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
> index b3aa47e..6c64cb7 100644
> --- a/Documentation/trace/events.txt
> +++ b/Documentation/trace/events.txt
> @@ -532,12 +532,14 @@ The following commands are supported:
>
> 'hist' triggers add a 'hist' file to each event's subdirectory.
> Reading the 'hist' file for the event will dump the hash table in
> - its entirety to stdout. Each printed hash table entry is a simple
> - list of the keys and values comprising the entry; keys are printed
> - first and are delineated by curly braces, and are followed by the
> - set of value fields for the entry. By default, numeric fields are
> - displayed as base-10 integers. This can be modified by appending
> - any of the following modifiers to the field name:
> + its entirety to stdout. If there are multiple hist triggers
> + attached to an event, there will be a table for each trigger in the
> + output. Each printed hash table entry is a simple list of the keys
> + and values comprising the entry; keys are printed first and are
> + delineated by curly braces, and are followed by the set of value
> + fields for the entry. By default, numeric fields are displayed as
> + base-10 integers. This can be modified by appending any of the
> + following modifiers to the field name:
>
> .hex display a number as a hex value
> .sym display an address as a symbol
> @@ -1629,3 +1631,140 @@ The following commands are supported:
> .
> .
> .
> +
> + The following example demonstrates how multiple hist triggers can be
> + attached to a given event. This capability can be useful for
> + creating a set of different summaries derived from the same set of
> + events, or for comparing the effects of different filters, among
> + other things.
> +
> + # echo 'hist:keys=skbaddr.hex:vals=len if len < 0' > \
> + /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger
> + # echo 'hist:keys=skbaddr.hex:vals=len if len > 4096' > \
> + /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger
> + # echo 'hist:keys=skbaddr.hex:vals=len if len == 256' > \
> + /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger
> + # echo 'hist:keys=skbaddr.hex:vals=len' > \
> + /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger
> + # echo 'hist:keys=len:vals=common_preempt_count' > \
> + /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger
AFAIK other tracefs files honor the truncation flag so open for
writing would destroy other hist triggers. What do you think?
> +
> + The above set of commands create four triggers differing only in
> + their filters, along with a completely different though fairly
> + nonsensical trigger.
[SNIP]
> @@ -1289,22 +1368,18 @@ static int event_hist_trigger_func(struct event_command *cmd_ops,
>
> trigger_data->private_data = hist_data;
>
> + if (param) { /* if param is non-empty, it's supposed to be a filter */
> + ret = cmd_ops->set_filter(param, trigger_data, file);
Maybe you want to check ->set_filter being NULL first. :)
Thanks,
Namhyung
> + if (ret < 0)
> + goto out_free;
> + }
> +
> if (glob[0] == '!') {
> cmd_ops->unreg(glob+1, trigger_ops, trigger_data, file);
> ret = 0;
> goto out_free;
> }
>
> - if (!param) /* if param is non-empty, it's supposed to be a filter */
> - goto out_reg;
> -
> - if (!cmd_ops->set_filter)
> - goto out_reg;
> -
> - ret = cmd_ops->set_filter(param, trigger_data, file);
> - if (ret < 0)
> - goto out_free;
> - out_reg:
> ret = cmd_ops->reg(glob, trigger_ops, trigger_data, file);
> /*
> * The above returns on success the # of triggers registered,
> @@ -1337,7 +1412,7 @@ static struct event_command trigger_hist_cmd = {
> .needs_rec = true,
> .func = event_hist_trigger_func,
> .reg = hist_register_trigger,
> - .unreg = unregister_trigger,
> + .unreg = hist_unregister_trigger,
> .get_trigger_ops = event_hist_get_trigger_ops,
> .set_filter = set_trigger_filter,
> };
> @@ -1364,7 +1439,6 @@ hist_enable_trigger(struct event_trigger_data *data, void *rec)
> test->paused = false;
> else
> test->paused = true;
> - break;
> }
> }
> }
> --
> 1.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists