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]
Date:   Fri, 08 Sep 2017 10:37:28 -0500
From:   Tom Zanussi <tom.zanussi@...ux.intel.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     tglx@...utronix.de, mhiramat@...nel.org, namhyung@...nel.org,
        vedang.patel@...el.com, bigeasy@...utronix.de,
        joel.opensrc@...il.com, joelaf@...gle.com,
        mathieu.desnoyers@...icios.com, baohong.liu@...el.com,
        linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org
Subject: Re: [PATCH v2 28/40] tracing: Add support for 'field variables'

On Thu, 2017-09-07 at 19:43 -0400, Steven Rostedt wrote:
> On Tue,  5 Sep 2017 16:57:40 -0500
> Tom Zanussi <tom.zanussi@...ux.intel.com> wrote:
> 
> > Users should be able to directly specify event fields in hist trigger
> > 'actions' rather than being forced to explicitly create a variable for
> > that purpose.
> > 
> > Add support allowing fields to be used directly in actions, which
> > essentially does just that - creates 'invisible' variables for each
> > bare field specified in an action.  If a bare field refers to a field
> > on another (matching) event, it even creates a special histogram for
> > the purpose (since variables can't be defined on an existing histogram
> > after histogram creation).
> 
> Can you show some examples here to describe what you mean better?
> 

Yeah, I guess that description is pretty opaque without an example.

Here's a simple example that demonstrates both.  Basically the onmatch()
action creates a list of variables corresponding to the parameters of
the synthetic event to be generated, and then uses those values to
generate the event.  So for the wakeup_latency synthetic event 'call'
below the first param, $wakeup_lat, is a variable defined explicitly on
sched_switch, where 'next_pid' is just a normal field on sched_switch,
and prio is a normal field on sched_waking.

Since the mechanism works on variables, those two normal fields just
have 'invisible' variables created internally for them.  In the case of
'prio', which is on another event, we actually need to create an
additional hist trigger and define the invisible event on that, since
once a hist trigger is defined, variables can't be added to it later.

echo 'wakeup_latency u64 lat; pid_t pid; int prio' >> /sys/kernel/debug/tracing/synthetic_events

echo 'hist:keys=pid:ts0=$common_timestamp.usecs >> /sys/kernel/debug/tracing/events/sched/sched_waking/trigger

echo 'hist:keys=next_pid:wakeup_lat=$common_timestamp.usecs-$ts0:
      onmatch(sched.sched_waking).wakeup_latency($wakeup_lat,next_pid,prio)
      >> /sys/kernel/debug/tracing/events/sched/sched_switch/trigger

Anyway, I just tested it and a recent change broke the latter case, will
add the fix to v3.

Tom 



Powered by blists - more mailing lists