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.