linux-kernel - Re: [PATCH 5/5] tracing: Add 'hash' event trigger command

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: <533D22E6.4000607@hitachi.com>
Date:	Thu, 03 Apr 2014 17:59:18 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Tom Zanussi <tom.zanussi@...ux.intel.com>
Cc:	rostedt@...dmis.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] tracing: Add 'hash' event trigger command

Hi Tom,

(2014/03/27 13:54), Tom Zanussi wrote:
> Hash triggers allow users to continually hash events which can then be
> dumped later by simply reading the trigger file.  This is done
> strictly via one-liners and without any kind of programming language.
> 
> The syntax follows the existing trigger syntax:
> 
>   # echo hash:key(s):value(s)[:sort_keys()][ if filter] > event/trigger
> 
> The values used as keys and values are just the fields that define the
> trace event and available in the event's 'format' file.  For example,
> the kmalloc event:
> 
> root@ie:/sys/kernel/debug/tracing/events/kmem/kmalloc# cat format
> name: kmalloc
> ID: 370
> format:
>         field:unsigned short common_type;       offset:0;       size:2; signed:0;
>         field:unsigned char common_flags;       offset:2;       size:1; signed:0;
>         field:unsigned char common_preempt_count;       offset:3;       size:1;signed:0;
>         field:int common_pid;   offset:4;       size:4; signed:1;
> 
>         field:unsigned long call_site;  offset:8;       size:4; signed:0;
>         field:const void * ptr; offset:12;      size:4; signed:0;
>         field:size_t bytes_req; offset:16;      size:4; signed:0;
>         field:size_t bytes_alloc;       offset:20;      size:4; signed:0;
>         field:gfp_t gfp_flags;  offset:24;      size:4; signed:0;
> 
> The key can be made up of one or more of these fields and any number of
> values can specified - these are automatically tallied in the hash entry
> any time the event is hit.  Stacktraces can also be used as keys.
> 
> For example, the following uses the stacktrace leading up to a kmalloc
> as the key for hashing kmalloc events.  For each hash entry a tally of
> the bytes_alloc field is kept.  Dumping out the trigger shows the sum
> of bytes allocated for each execution path that led to a kmalloc:
> 
>   # echo 'hash:call_site:bytes_alloc' > /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
>   # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger

I like the basic idea :) but I'm confused the interface what you're introduced.
I suppose that the "trigger" file is for control triggers on the event, so that
user can check what trigger rules are set on the event and remove it.
But in this patch, that is also used for a data path.

I'd like to suggest adding new "hash" file under events/GROUP/EVENT/, which is
only for dumping the hash data, and keep the "trigger" as a control path.
This makes users easier to build their own tools on the ftrace facility.

Thank you,


-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
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/