linux-kernel - 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:	Tue, 31 Mar 2015 17:04:18 +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: [RFC] perf probe: -x option position issue

(2015/03/31 4:48), Arnaldo Carvalho de Melo wrote:
> Em Mon, Mar 30, 2015 at 07:46:55PM +0200, Jiri Olsa escreveu:
>> hi,
>> Martin found out following issue.. having following ex binary:
>>
>> ---
>> int main(void)
>> {
>>         return 0;
>> }
>> ---
>>
>> following will create uprobe on main:
>>
>>   [root@...l-per510-01 perf]# gcc -g -o ex ex.c
>>   [root@...l-per510-01 perf]# ./perf probe -x ./ex -a main
>>   Added new event:
>>     probe_ex:main        (on main in /root/linux/tools/perf/ex)
>>
>>   You can now use it in all perf tools, such as:
>>
>>           perf record -e probe_ex:main -aR sleep 1
>>
>>   [root@...l-per510-01 perf]# cat /sys/kernel/debug/tracing/uprobe_events 
>>   p:probe_ex/main /root/linux/tools/perf/ex:0x00000000000004f6
>>
>>
>> while following will create (?) kprobe with complain in dmesg:
> 
> Right, it looks like it will create the probe on the currently selected
> DSO, which, if you have none, will be the kernel, thus the kprobe
> (probe:main), while if you do a '-x ./ex -a main' you are selecting the
> 'ex' DSO and then asking for the probe to be added to a function named
> 'main', on that DSO, that 'perf probe' realizes is a userspace binary,
> thus creates a uprobe: probe_%DSONAME:%FUNCTIONAME.

Right, but this looks strange and not easy to expect.

> 
> I wonder if I can do:
> 
> [root@...andy acme]# perf probe -a icmp_rcv -x ./ex -a main
> Probe point 'icmp_rcv' not found.
>   Error: Failed to add events.

Ah, this should be fixed. Even with multiple -x, it fails.

# ./perf probe -x /usr/lib64/libc-2.17.so -a malloc -x ./perf -a main

 usage: perf probe [<options>] 'PROBEDEF' ['PROBEDEF' ...]
    or: perf probe [<options>] --add 'PROBEDEF' [--add 'PROBEDEF' ...]
    or: perf probe [<options>] --del '[GROUP:]EVENT' ...
    or: perf probe --list
    or: perf probe [<options>] --line 'LINEDESC'
    or: perf probe [<options>] --vars 'PROBEPOINT'

    -x, --exec <executable|path>
                          target executable name or path

...

I'd like to start with setting up the event only on single binary,
and showing appropriate error message.

> 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
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
perf probe -x BIN -a XXX -x BIN2 -a YYY
	 -> setup XXX on BIN and YYY on BIN2

Thank you,

> 
> - Arnaldo
>  
>>   [root@...l-per510-01 perf]# gcc -g -o ex ex.c
>>   [root@...l-per510-01 perf]# ./perf probe -a main -x ./ex
>>   Added new event:
>>     probe:main           (on main in ex)
>>
>>   You can now use it in all perf tools, such as:
>>
>>           perf record -e probe:main -aR sleep 1
>>
>>   [root@...l-per510-01 perf]# dmesg | tail -2
>>   [16986.182159] Could not insert probe at ex:main+0: -2
>>   [16986.187030] This probe might be able to register aftertarget module is loaded. Continue.
>>
>>
>> that does not seem as an expected behaviour, or am I missing something?
>>
>> thanks,
>> jirka
> 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
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/