linux-kernel - Re: Re: Re: [RFC PATCH perf/core v2 00/16] perf-probe --cache and SDT support

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: <20150724075519.GA19672@sejong>
Date:	Fri, 24 Jul 2015 16:55:19 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Hemant Kumar <hemant@...ux.vnet.ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org,
	Adrian Hunter <adrian.hunter@...el.com>,
	Ingo Molnar <mingo@...hat.com>, Jiri Olsa <jolsa@...nel.org>,
	Borislav Petkov <bp@...e.de>
Subject: Re: Re: Re: [RFC PATCH perf/core v2 00/16] perf-probe --cache and
 SDT support

Hi Masami and Arnaldo,

On Fri, Jul 24, 2015 at 01:24:53AM +0900, Masami Hiramatsu wrote:
> On 2015/07/23 23:01, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Jul 23, 2015 at 10:13:22PM +0900, Masami Hiramatsu escreveu:
> >> # perf list
> >>
> >> List of pre-defined events (to be used in -e):
> >> ...
> >>   libc:memory_heap_new                             [Tracepoint event]
> > 
> > Is it like this or is it like [ku]probes where we already have a
> > namespace qualifier, i.e.:
> > 
> > [root@zoo ~]# perf probe icmp_rcv
> > Added new event:
> >   probe:icmp_rcv       (on icmp_rcv)
> > 
> > You can now use it in all perf tools, such as:
> > 
> > 	perf record -e probe:icmp_rcv -aR sleep 1
> > 
> > [root@zoo ~]#
> > 
> > [root@zoo ~]# perf probe /lib64/libc-2.20.so malloc
> > Added new events:
> >   probe_libc:malloc    (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_1  (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_2  (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_3  (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_4  (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_5  (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_6  (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_7  (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_8  (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_9  (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_10 (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_11 (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_12 (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_13 (on malloc in /lib64/libc-2.20.so)
> >   probe_libc:malloc_14 (on malloc in /lib64/libc-2.20.so)
> > 
> > You can now use it in all perf tools, such as:
> > 
> > 	perf record -e probe_libc:malloc_14 -aR sleep 1
> > 
> > [root@zoo ~]#
> > 
> > "probe" for kernel events, "probe_%s" % DSO basename for userspace
> > events.
> > 
> > Why not continue with that and have SDTs use the probe_%s: namespace?
> > Sorry if this was already discussed here...
> 
> :) We are discussing about that in another thread, anyway, probe_%s can
> solve a little part of the clash of names.
> 
> > 
> > If there is some ambiguity, that can be resolved by explicitely setting
> > a new name, 'perf probe' has provision for that, right? I.e.:
> 
> Yes, but that means we'll have to give new names before using that.
> 
> Actually, SDT has "provider-name", "event-name" and "probe location" (also
> have arguments, but not supported). And provider name is not always same
> as the binary name. (actually, the application developers can use any
> name for it...)
> So adding something special prefix or detect clash before using will
> be the option.
> 
> The following patterns we've discussed.
> 
>  - <provider>:<name>
> 	simple, but could easily clash with others.
>  - probe_<provider>:<name>
>  - sdt_<provider>:<name>
> 	also simple and similar to current solution. but fragile against
> 	clash among SDTs.
>  - probe_<binary>:<provider>_<name>
> 	also simple, but if provider or/and name has '_', it is hard to
> 	split the provider and name. and fragile against clash among SDTs too.
>  - <provider>_<buildid>/<name>
> 	possible, but ugly since buildid is a random long xdigits(maybe cut up
> 	to 8 or 12 bytes).

As I said, we might allow name clashes as they're rare.  I don't want
to make it complex just for an uncommon case.  I think such a
duplicate name is fine as long as 'perf list' indicates it and 'perf
record' enable them all.

If we agreed to extend the event format, I'd like to keep it simple
and to make it optional to add more info (separated by colon?).

Maybe something like below.  Suppose we have 3 SDT events with a same
name:

 /some/where/dir1/libfoo1.so (build-id: 0x1234...) -->  foo:bar
 /some/where/dir2/libfoo1.so (build-id: 0x5678...) -->  foo:bar
 /some/where/dir2/libfoo2.so (build-id: 0xabcd...) -->  foo:bar

So perf list shows the single name, but also says it has 3 events.

  $ perf list sdt_foo:bar
  
  sdt_foo:bar (total 3 events)            [User SDT event]


  $ perf list -v sdt_foo:bar
  
  sdt_foo:bar:libfoo1.so:0x1234...        [User SDT event]
  sdt_foo:bar:libfoo1.so:0x5678...        [User SDT event]
  sdt_foo:bar:libfoo2.so:0xabcd...        [User SDT event]


Now perf record can accept any of these forms..

  # record all 3 events
  $ perf record -e 'sdt_foo:bar'

  # record 2 events from libfoo1.so
  $ perf record -e 'sdt_foo:bar:libfoo1.so'

  # record only 1 event
  $ perf record -e 'sdt_foo:bar:libfoo1.so:0x1234...'


What do you think?

Thanks,
Namhyung
--
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/