This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug uprobes/17660] New: @perf wont work with uprobes
- From: "Sergey dot Klyaus at Tune-IT dot Ru" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Fri, 28 Nov 2014 09:21:04 +0000
- Subject: [Bug uprobes/17660] New: @perf wont work with uprobes
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17660
Bug ID: 17660
Summary: @perf wont work with uprobes
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: uprobes
Assignee: systemtap at sourceware dot org
Reporter: Sergey.Klyaus@Tune-IT.Ru
Hello.
Debian 7
SystemTap 2.6
Linux kernels 3.12.6 and 3.18-rc6
I found that new versions of SystemTap support @perf, so I wanted to try it.
Here are the test script:
$ stap -v -e '
probe perf.hw.instructions
.process("/bin/bash")
.counter("insns") { }
probe process("/bin/bash").function("cd_builtin") {
printf(" insns = %d\n", @perf("insns"));
}'
In other shell I am saying 'cd /' and then this happens on logs:
[72998.472982] BUG: sleeping function called from invalid context at
/usr/local/share/systemtap/runtime/linux/perf.c:270
[72998.484901] in_atomic(): 1, irqs_disabled(): 0, pid: 4218, name: bash
[72998.492132] CPU: 14 PID: 4218 Comm: bash Tainted: G O 3.18.0-rc6
#1
[72998.492134] Hardware name: Dell Inc. PowerEdge R520/0XMC17, BIOS 2.3.3
07/10/2014
<some hex numbers>
[72998.492143] Call Trace:
[72998.492147] [<ffffffff813fbdf5>] dump_stack+0x4e/0x68
[72998.492150] [<ffffffff8105de73>] __might_sleep+0xf4/0xf9
[72998.492156] [<ffffffffa0493ade>] probe_2324+0x3e/0x168
[stap_2bef1fedd456caa44e79a3a3dc566d38_5026]
[72998.492160] [<ffffffffa0492d18>] stapiu_probe_prehandler+0x17f/0x309
[stap_2bef1fedd456caa44e79a3a3dc566d38_5026]
[72998.492163] [<ffffffff810e0306>] uprobe_notify_resume+0x419/0x83b
[72998.492166] [<ffffffff81400c10>] ? _raw_spin_unlock+0x9/0x13
[72998.492170] [<ffffffffa04905ab>] ? utrace_report_syscall_exit+0x31/0xdc
[stap_2bef1fedd456caa44e79a3a3dc566d38_5026]
[72998.492173] [<ffffffff81002763>] do_notify_resume+0x23/0x63
[72998.492176] [<ffffffff81402bb4>] paranoid_userspace+0x3f/0x42
As a side effect, looks like instructions is not measured at all.
As you can see, runtime/linux/perf.c calls might_sleep() - that is because perf
internally uses mutexes that might sleep. But uprobes are working through int3
on x86_64 and are notified via resume-path (during that no preemption is
expected, because we are already resuming task, so it is in_atomic()).
I see no clear solution. When I used perf, I had implemented own
perf_event_read_value() that did not have mutexes, but it caused some weird
values that I had to filter later.
Thanks in advance.
BR, Sergey.
--
You are receiving this mail because:
You are the assignee for the bug.