01:01 <sfix> i'm using a systemtap script to get a userspace backtrace on the return of a kernel function for a particular pid, but i'm getting a bunch of warnings about missing symbols for processes i dont want to trace which eventually ends with stap exiting due to too many errors. is there a way i can prevent that?

01:08 <sfix> ah, seems i missed the -x option, that does the trick if i add a check for target() in my probe

12:05 <fche> there you go!

12:05 <fche> sfix, and you could use other filters like execname()=="your_program" or uid()==$your_uid

12:10 <sfix> i was doing a check for pid() == $1 before and passing the pid in as an argument, but stap still unwind info for unrelated processes, using -x did the job!

12:10 <sfix> still wanted*

12:10 <fche> yeah, -x PID is a better way than passing a pid as a $1 type argument

12:11 <fche> (the runtime supports -x specially and allows module reuse, whereas $1 substitution requires a complete stap recompilation)

12:11 <sfix> ah, good to know

12:12 <sfix> i have another question about kernel backtraces, currently when i call sprint_backtrace() i only get the current frame and the next is shown as 0x0 (Inexact), is there something i'm doing wrong for that to be happening?

12:13 <fche> how deep within the kernel are you?

12:13 <sfix> i was using kprobes before and calling save_stack_trace() within my probe before, which worked quite well

12:14 <sfix> my probe is on an LSM hook

12:14 <fche> in a module? wonder if its debuginfo (well, unwind data) is not available without stap -d foo.ko or stap --all-modules

12:14 <sfix> ah no, the LSM is in-kernel (it's selinux)

12:14 <sfix> i do have debuginfo available for the kernel i'm running

12:15 <fche> unwinding relies on a small piece only ... does print_backtrace() give something more useful?

12:15 <sfix> good question, let me try that

12:17 <sfix> nope, unfortunately not

12:18 <fche> our backtracer prefers full unwinding vs. frame-pointer-based heuristics, but can back down to it. so if it's giving nothing, something's strange

12:18 <sfix> for a bit of context my stap script currently looks like this: http://termbin.com/o0bg and i'm invoking it with stap -d /usr/bin/vim --ldd -x $pid

12:19 <sfix> does providing -d for a program/shlib maybe prevent unwind info for kernel symbols being available?

12:28 <fche> no

12:29 <fche> the kernel.function() probe should cause -d kernel to be implicit

12:29 <fche> but you could try manually adding it just for giggles

12:29 <fche> what is the output?

12:35 <sfix> sure, just a sec

12:37 <sfix> hmm, nope, still just 2 lines in the backtrace:

12:37 <sfix> 0xffffffffb1383950 : avc_has_perm+0x0/0x1a0 [kernel]

12:37 <sfix> 0x0 (inexact)

12:51 <fche> hm weird, I wonder if maybe some assembly code is what's calling this function,

12:51 <fche> and the assembly doesn't include correct .cfi* codes to allow unwinding through it

12:54 <sfix> well that function is called by other SELinux functions, so if i make it a .return probe instead then calling print_backtrace() gets me the correct info for the caller, but still 0x0 as the 2nd item

12:55 <fche> hm could try stap -DDEBUG_UNWIND for more data, but I suspect something is weird about the caller function.

12:58 <sfix> ah unwind_frame:1178: Module /usr/lib/debug/usr/lib/modules/4.10.8-100.fc24.x86_64/vmlinux: no unwind frame data

13:16 <fche> a fedora kernel should just work (tm) dammit ... wonder what's up

13:58 <fche> ok seeing something similar over here. something has definitely gotten pooched

14:02 <fche> filed https://bugzilla.redhat.com/show_bug.cgi?id=1442561

14:03 <fche> methinks there's a kernel build change/problem, but we'll get to the bottom of it

14:04 <sfix> fche: thanks for the help! i'll keep an eye on the BZ and leave a comment if i get anything new

14:09 <fche> righto