From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: Francis Moreau <francis.moro@gmail.com>
Cc: linux-perf-users@vger.kernel.org,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Subject: Re: perf-probe: issue with latest fedora kernel
Date: Mon, 13 Dec 2010 12:21:59 -0200 [thread overview]
Message-ID: <20101213142159.GF5407@ghostprotocols.net> (raw)
In-Reply-To: <m2sjy1stuf.fsf@gmail.com>
Em Mon, Dec 13, 2010 at 02:08:56PM +0100, Francis Moreau escreveu:
> Arnaldo Carvalho de Melo <acme@ghostprotocols.net> writes:
> > Em Mon, Dec 13, 2010 at 11:02:52AM +0100, Francis Moreau escreveu:
> >> Arnaldo Carvalho de Melo <acme@ghostprotocols.net> writes:
> >> > Em Thu, Dec 09, 2010 at 04:00:08PM +0100, Francis Moreau escreveu:
> >> >> I'm trying to use perf-probe(1) with the latest F14 kernel
> >> >> (2.6.35.9-64.fc14.x86_64).
> >> >> I also installed kernel-debug-debuginfo-2.6.35.9-64.fc14.x86_64 which
> >> >> contains the running vmlinux image AFAICT.
> >> > Can you try using:
> >> > $ perf probe -k /usr/lib/debug/lib/modules/2.6.35.9-64.fc14.x86_64.debug/vmlinux <rest of the probe definition>
> >> > So that it tries it directly instead of looking into the buildid cache?
> >> Does anybody know where I can report this issue to Fedora community ?
> > Please create a ticket at:
> > http://bugzilla.redhat.com
> Hmm, I don't think that any patches recently posted in response of this
> thread will solve the problem.
>
> The primarily concern here, is that the running kernel has a different
> build-id than the debug image installed by the corresponding debug
> package.
So? The problem for me is that:
1. looks at /sys/kernel/notes and gets the running kernel build-id
2. fails to locate a vmlinux with a matching build-id
3. ignores the -k specified path
4. The mentioned patch makes it consider the -k specified path
So it should look at the -k specified path and make sure that it has a
matching build-id, if it has, problem solved, no?
> I think it's a distrib issue, hence my question about Fedora report.
Well, here I have fedora 14 and:
[root@felicio /]# uname -r
2.6.35.9-64.fc14.x86_64
[root@felicio /]# rpm -qa | grep kernel-debuginfo
kernel-debuginfo-2.6.35.9-64.fc14.x86_64
kernel-debuginfo-common-x86_64-2.6.35.9-64.fc14.x86_64
[root@felicio /]# perf probe -L icmp_rcv
Failed to open net/ipv4/icmp.c: No such file or directory
Error: Failed to show lines. (-2)
<icmp_rcv:0>
[root@felicio /]# rpm -ql kernel-debuginfo-common-x86_64 | grep net/ipv4/icmp.c
/usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64/net/ipv4/icmp.c
[root@felicio /]# cd /usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64/
[root@felicio linux-2.6.35.x86_64]# perf probe -L icmp_rcv | head -30
Source file is shorter than expected.
<icmp_rcv:0>
0 int icmp_rcv(struct sk_buff *skb)
1 {
struct icmphdr *icmph;
struct rtable *rt = skb_rtable(skb);
struct net *net = dev_net(rt->u.dst.dev);
6 if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb)) {
struct sec_path *sp = skb_sec_path(skb);
int nh;
10 if (!(sp && sp->xvec[sp->len - 1]->props.flags &
XFRM_STATE_ICMP))
goto drop;
14 if (!pskb_may_pull(skb, sizeof(*icmph) + sizeof(struct iphdr)))
goto drop;
nh = skb_network_offset(skb);
skb_set_network_header(skb, sizeof(*icmph));
20 if (!xfrm4_policy_check_reverse(NULL, XFRM_POLICY_IN, skb))
goto drop;
skb_set_network_header(skb, nh);
}
26 ICMP_INC_STATS_BH(net, ICMP_MIB_INMSGS);
[root@felicio linux-2.6.35.x86_64]# cat /proc/net/snmp | grep Icmp:
Icmp: InMsgs InErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps
Icmp: 4 1 2 0 0 0 0 1 1 0 0 0 0 119 0 116 0 0 0 0 3 0 0 0 0 0
[root@felicio linux-2.6.35.x86_64]# perf probe icmp_rcv:26
Add new event:
probe:icmp_rcv (on icmp_rcv:26)
You can now use it on all perf tools, such as:
perf record -e probe:icmp_rcv -aR sleep 1
[root@felicio linux-2.6.35.x86_64]# perf record -e probe:icmp_rcv -ag
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.535 MB perf.data (~23357 samples) ]
[root@felicio linux-2.6.35.x86_64]# perf report
# Events: 3 cycles
#
# Overhead Command Shared Object Symbol
# ........ ............... ................. ......
#
66.67% swapper [kernel.kallsyms] [k] icmp_rcv
|
--- icmp_rcv
ip_local_deliver_finish
NF_HOOK.clone.8
ip_local_deliver
ip_rcv_finish
NF_HOOK.clone.8
ip_rcv
__netif_receive_skb
netif_receive_skb
napi_skb_finish
napi_gro_receive
igb_poll
net_rx_action
__do_softirq
call_softirq
do_softirq
irq_exit
do_IRQ
common_interrupt
default_idle
cpu_idle
start_secondary
33.33% ssh [kernel.kallsyms] [k] icmp_rcv
|
--- icmp_rcv
ip_local_deliver_finish
NF_HOOK.clone.8
ip_local_deliver
ip_rcv_finish
NF_HOOK.clone.8
ip_rcv
__netif_receive_skb
netif_receive_skb
napi_skb_finish
napi_gro_receive
igb_poll
net_rx_action
__do_softirq
call_softirq
[root@felicio linux-2.6.35.x86_64]#
[root@felicio linux-2.6.35.x86_64]# cat /proc/net/snmp | grep Icmp:
Icmp: InMsgs InErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps
Icmp: 7 1 2 0 0 0 0 4 1 0 0 0 0 123 0 117 0 0 0 0 3 3 0 0 0 0
[root@felicio linux-2.6.35.x86_64]#
All seems to work, right?
There are two problems here:
on the 'report' header, as we didn't collect "cycles", but
"probe:icmp_rcv" events, that is another fix that needs to be backported to
fedora, but a minor one.
Also 'perf probe -L' should look use
/usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64 as a prefix to look for
sources.
That can be found using:
[root@felicio linux-2.6.35.x86_64]# readelf -wi /usr/lib/debug/lib/modules/2.6.35.9-64.fc14.x86_64/vmlinux | grep DW_AT_comp_dir | head -5
<2e> DW_AT_comp_dir : /usr/src/debug////////kernel-2.6.35.fc14/linux-2.6.35.x86_64
<95> DW_AT_comp_dir : (indirect string, offset: 0x24d0): /usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64
<75e8> DW_AT_comp_dir : (indirect string, offset: 0x24d0): /usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64
<900e> DW_AT_comp_dir : (indirect string, offset: 0x24d0): /usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64
<16670> DW_AT_comp_dir : (indirect string, offset: 0x24d0): /usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64
[root@felicio linux-2.6.35.x86_64]#
<0><8b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<8c> DW_AT_producer : (indirect string, offset: 0x22f4): GNU C 4.5.1 20100924 (Red Hat 4.5.1-4)
<90> DW_AT_language : 1 (ANSI C)
<91> DW_AT_name : (indirect string, offset: 0x37a): arch/x86/kernel/head64.c
<95> DW_AT_comp_dir : (indirect string, offset: 0x24d0): /usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64
<99> DW_AT_low_pc : 0x0
<a1> DW_AT_entry_pc : 0x0
<a9> DW_AT_ranges : 0x340
<ad> DW_AT_stmt_list : 0x114
I.e. using the DW_AT_comp_dir attribute in the DW_TAG_compile_unit DWARF tags,
Masami?
All this with:
[root@felicio linux-2.6.35.x86_64]# type perf
perf is hashed (/usr/bin/perf)
[root@felicio linux-2.6.35.x86_64]# rpm -qf /usr/bin/perf
perf-2.6.35.9-64.fc14.x86_64
[root@felicio linux-2.6.35.x86_64]#
I.e. the perf binary shipping in fedora, without the recent patches.
To finish the session:
[root@felicio linux-2.6.35.x86_64]# perf probe --list
probe:icmp_rcv (on icmp_rcv:26@ipv4/icmp.c)
[root@felicio linux-2.6.35.x86_64]# perf probe --del icmp_rcv
Remove event: probe:icmp_rcv
[root@felicio linux-2.6.35.x86_64]# perf probe --list
[root@felicio linux-2.6.35.x86_64]#
And if you run it in verbose mode we can see what was the vmlinux file used:
[root@felicio linux-2.6.35.x86_64]# perf probe -v icmp_rcv:26
probe-definition(0): icmp_rcv:26
symbol:icmp_rcv file:(null) line:26 offset:0 return:0 lazy:(null)
0 arguments
Looking at the vmlinux_path (6 entries long)
Using /usr/lib/debug/lib/modules/2.6.35.9-64.fc14.x86_64/vmlinux for symbols
Try to open /usr/lib/debug/lib/modules/2.6.35.9-64.fc14.x86_64/vmlinux
Probe line found: line[571]:999 addr:0xffffffff81416655
Probe point found: icmp_rcv+208
find 1 kprobe_trace_events.
Opening /sys/kernel/debug/tracing/kprobe_events write=1
Add new event:
Writing event: p:probe/icmp_rcv icmp_rcv+208
probe:icmp_rcv (on icmp_rcv:26)
You can now use it on all perf tools, such as:
perf record -e probe:icmp_rcv -aR sleep 1
[root@felicio linux-2.6.35.x86_64]#
It was /usr/lib/debug/lib/modules/2.6.35.9-64.fc14.x86_64/vmlinux, that is present on:
[root@felicio linux-2.6.35.x86_64]# rpm -qf /usr/lib/debug/lib/modules/2.6.35.9-64.fc14.x86_64/vmlinux
kernel-debuginfo-2.6.35.9-64.fc14.x86_64
And...
[root@felicio linux-2.6.35.x86_64]# perf buildid-list
882b1b53eb1d653200e8fa7100273aa8493896c4 [kernel.kallsyms]
This is the build-id of the running kernel, and:
[root@felicio linux-2.6.35.x86_64]# perf buildid-cache -v --add /usr/lib/debug/lib/modules/2.6.35.9-64.fc14.x86_64/vmlinux
Adding 882b1b53eb1d653200e8fa7100273aa8493896c4 /usr/lib/debug/lib/modules/2.6.35.9-64.fc14.x86_64/vmlinux: FAIL
/usr/lib/debug/lib/modules/2.6.35.9-64.fc14.x86_64/vmlinux already in the cache
[root@felicio linux-2.6.35.x86_64]#
The running kernel build-id matches the build-id in the vmlinux file found in
the kernel-debuginfo package.
So can you please give us the versions for the kernel, kernel-debuginfo package?
Perhaps you have a new debuginfo package and is running an older kernel?
Use the perf buildid-list trick to get the build-id in readable format.
Thanks,
- Arnaldo
next prev parent reply other threads:[~2010-12-13 14:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-09 15:00 perf-probe: issue with latest fedora kernel Francis Moreau
2010-12-09 15:35 ` Arnaldo Carvalho de Melo
2010-12-09 16:34 ` Francis Moreau
2010-12-10 3:27 ` Masami Hiramatsu
2010-12-10 7:53 ` Franck Bui-Huu
2010-12-10 8:26 ` Masami Hiramatsu
2010-12-10 13:00 ` Franck Bui-Huu
2010-12-10 13:06 ` [PATCH 1/2] perf-probe: do use the kernel image path given by 'k' option Franck Bui-Huu
2010-12-10 13:07 ` [PATCH 2/2] perf-probe: fail if the kernel image contains no symbol Franck Bui-Huu
2010-12-10 7:30 ` perf-probe: issue with latest fedora kernel Franck Bui-Huu
2010-12-12 14:08 ` Arnaldo Carvalho de Melo
2010-12-12 22:15 ` Franck Bui-Huu
2010-12-13 16:40 ` Arnaldo Carvalho de Melo
2010-12-13 10:02 ` Francis Moreau
2010-12-13 12:58 ` Arnaldo Carvalho de Melo
2010-12-13 13:08 ` Francis Moreau
2010-12-13 14:04 ` Masami Hiramatsu
2010-12-13 14:16 ` Francis Moreau
2010-12-13 19:08 ` Francis Moreau
2010-12-13 14:25 ` Arnaldo Carvalho de Melo
2010-12-13 14:21 ` Arnaldo Carvalho de Melo [this message]
2010-12-13 15:11 ` Francis Moreau
2010-12-13 16:40 ` Arnaldo Carvalho de Melo
2010-12-13 19:08 ` Francis Moreau
2010-12-13 19:17 ` Arnaldo Carvalho de Melo
2010-12-13 19:32 ` Francis Moreau
2010-12-15 8:57 ` Masami Hiramatsu
2010-12-15 18:53 ` Arnaldo Carvalho de Melo
2010-12-23 13:59 ` Franck Bui-Huu
2010-12-27 20:50 ` Franck Bui-Huu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101213142159.GF5407@ghostprotocols.net \
--to=acme@ghostprotocols.net \
--cc=francis.moro@gmail.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).