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: <20150727140320.GF22022@danjae.kornet>
Date:	Mon, 27 Jul 2015 23:03:20 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Arnaldo Carvalho de Melo <acme@...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

Hi Arnaldo,

On Fri, Jul 24, 2015 at 12:52:37PM -0300, Arnaldo Carvalho de Melo wrote:
> 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.

OK.


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

I'm fine with using @.


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

Then it should use @ here too.


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

Fair enough.


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

Either is fine to me.  Mayb we can add a config option to select the
default bahavior.. :)


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

IMHO @ looks perfect for pathnames but I don't know about build-id as
it can be thought as some address.  Anyway I still think @ is a good
choice though. ;-)


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

Ah, good idea.


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

Agreed.

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/