linux-kernel - Re: Re: [RFC] perf probe: -x option position issue

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:	Wed, 01 Apr 2015 17:37:10 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Arnaldo Carvalho de Melo <acme@...radead.org>
CC:	Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	David Ahern <dsahern@...il.com>, linux-kernel@...r.kernel.org,
	Martin Cermak <mcermak@...hat.com>
Subject: Re: Re: [RFC] perf probe: -x option position issue

(2015/03/31 22:33), Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 31, 2015 at 05:04:18PM +0900, Masami Hiramatsu escreveu:
>> (2015/03/31 4:48), Arnaldo Carvalho de Melo wrote:
>>> No, I can't, I'd say we should support that, i.e. inserting multiple
>>> probes per command line, for different DSOs, etc. I.e. the above would
>>> be equivalent to these two calls:
> 
>>> [root@...andy acme]# perf probe -a 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@...andy acme]# perf probe -x ./ex -a main
>>> Added new event:
>>>   probe_ex:main        (on main in /home/acme/ex)
> 
>>> You can now use it in all perf tools, such as:
> 
>>> 	perf record -e probe_ex:main -aR sleep 1
> 
>>> [root@...andy acme]#
> 
>> OK, finally we should support that.
> 
>>> But it isn't like that, so, yes, what you report is a bug, both for your
>>> expectation (that I think is that it should put a uprobes with both your
>>> examples) and for mine (that it would add the first to the kernel, and
>>> the second to the selected DSO via -x).
> 
>> Yes, both are bugs. I'll fix that.
> 
>> BTW, let me check that the below behaviors are OK for you.
> 
>> perf probe -x BIN -a XXX
>> 	 -> setup XXX on BIN
> 
> Ok
> 
>> perf probe -a XXX -x BIN
>> 	 -> setup XXX on BIN
>> perf probe -a XXX -x BIN -a YYY
>> 	 -> setup XXX on kernel and YYY on BIN
> 
> The two above are inconsistent, I think, first one, for me, doesn't make
> sense, i.e. it says: Add XXX to the selected DSO, which, as none was
> specified at that point, should be the kernel, right?

OK.

> 
> I.e. if we do:
> 
>> perf probe -a XXX
> 
> Without that extra -x that is coming _after_ the command to add a probe
> to XXX (-a XXX), what is that the tool should do (does from day 1, when
> 'probe' was first introduced in tools/perf/):
> 
> Add a probe to XXX _in the kernel_, i.e. not specifying a DSO means: its
> for the kernel.
> 
> So, for me:
> 
>> perf probe -a XXX -x BIN
>> 	 -> setup XXX on BIN
> 
> Is invalid (or inocuous if what one wants is to add a probe for XXX on
> the BIN dso), because it doesn't make sense _if you want to support
> adding multiple probes for different DSOs on the same command line_,
> because it would mean:
> 
>   Add a probe to XXX _in the kernel_, then select BIN as the DSO for
> which probes will be then specified, but in this example, none are
> specified after that "-x BIN", so, I think that:
> 
>  perf probe -a XXX -x BIN
> 
> and:
> 
>  perf probe -a XXX
> 
> Mean the same thing, i.e. add a probe for XXX in the kernel.

OK, so if we have -x BIN after -a, it should have an error, since
that may be not what the user intend.

>> perf probe -x BIN -a XXX -x BIN2 -a YYY
>> 	 -> setup XXX on BIN and YYY on BIN2
>  
> Ok.
> 
> Also, more generically, I think that:
> 
> perf probe -a AAA -a BBB -a CCC -a DDD -x /lib64/libc-2.17.so -a malloc -a free \
>            -x /usr/lib64/libthread_db-1.0.so -a td_lookup -a td_thr_event_enable
> 
> Should add kprobes for AAA, BBB, CCC and DDD in the kernel, uprobes for
> malloc and free on libc and uprobes for td_lookup and
> td_thr_event_enable on libthread_db.

Yes, that is what I'll do on perf probe. All the probes after -x XXX are
defined on XXX binary (or module).

> 
> Making it even more compact would be a bonus:
> 
> perf probe -a AAA,BBB,CCC,DDD -x /lib64/libc-2.17.so -a malloc,free \
>            -x /usr/lib64/libthread_db-1.0.so -a td_lookup,td_thr_event_enable
> 
> :-)

Sorry, this does not fit to current syntax of probe definition, since
we may have some arguments on each event...

Thank you,

-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
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/