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: <20150724155237.GA300@kernel.org>
Date:	Fri, 24 Jul 2015 12:52:37 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	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

Em Fri, Jul 24, 2015 at 04:55:19PM +0900, Namhyung Kim escreveu:
> 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:

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

I made some comments about enabling it all by default, look below.
 
> 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?).

Reading this again after writing what is below: my suggestion is to use
@, see rationale below.
 
> 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]

I would show what desambiguates them in non verbose mode, i.e., the
above would be:

   $ perf list sdt_foo:bar

   sdt_foo:bar:dir1/libfoo1.so   [User SDT event]
   sdt_foo:bar:dir2/libfoo1.so   [User SDT event]
   sdt_foo:bar:libfoo2.so        [User SDT event]

 The -v one would should both the full path and the buildid, but this
is just polishing up the default output a bit to make it more
informative.

	Now what should be the default when one does:

   perf record -e sdt_foo:bar

        Will it enable all events or bail out and state that multiple
events with that name matches, requiring a '--all-matches' to really
apply it to all events with the same name?

	Humm, this probably will not be that common, so perhaps just
use all matches by default while telling the user that all those places
were used and if the user wants just one of them, be more precise,
adding somehow a disambiguator.

	That would be something like this:

    perf record -e sdt_foo:bar:0x1234

	Or perhaps:

    perf record -e sdt_foo:bar@...234

	Because in this case the 'at' meaning of '@' makes sense, i.e.
use the std_foo:bar event at the DSO with a 0x1234 buildid?

	Additionally, for people that don't want to mess with buildids
because its environment is deemed well controlled and this works and is
unambiguous, looking at the LD_LIBRARY_PATH or equivalent:

    perf record -e sdt_foo:bar@...foo2

	Full paths could be used as well.
> 
>   $ 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?

If nothing prevents using @ with the meaning of "event at LOCATION"
where LOCATION is a buildid (noticed because it starts with 0x) or
a library name or pathname, then that looks more natural.

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