06:57 <wmealing`> the topic always makes me wonder for a bit

06:57 <wmealing`> so if nobody is here, the conversation will be logged

06:58 <wmealing`> watch what you're saying, FCHE is always loggiiiiinnng

06:58 <wmealing`> fche: i didn't find a nice way to replace that function

06:59 <wmealing`> your idea seemed to work though

11:25 <fche> hey wade

11:27 <fche> the cve workaround idea? or the CRAZY BAD MAN rewrite pt_regs->pc to jump out of a function idea?

12:34 <wmealing`> fche: bit of both

12:35 <wmealing`> fche: i kinda ended up just doing a long jump to the return instruction location

12:35 <wmealing`> thats a bad idea btw.

12:35 <wmealing`> either way i think i'll need to find a way around it more and more

12:35 <wmealing`> as i'm going to have to do this often

12:36 <wmealing`> there are plenty of "docz" on how to override syscalls

12:36 <wmealing`> most of which is not functional because the table is no longer public

12:36 <wmealing`> however even if it was, thats only going to be a small % of the cases.

12:37 <wmealing`> i thought perhaps some kind of ebpf filter

12:37 <wmealing`> but also, not a great idea.

12:55 <fche> with future gcc & debuginfo, stap at least has a hope of identifying function exit points / epilogues, so as to be able to branch there

12:56 <fche> hm, dtrace, bless its heart, does or did function-return probing by searching the machine code for epilogue type byte sequences; surprised it worked, but then they use framepointers everywhere, so that may help

13:10 <irker038> systemtap: dsmith systemtap.git:refs/heads/master * release-3.1-204-gd5ab5fe / testsuite/systemtap.syscall/aio.c: Correct a small bug in the aio syscall testcase. http://tinyurl.com/y7jb64qm

13:43 <sj0rz> it's not too hard to find the exit point using decompilation and some recursive block analysis right

13:43 <sj0rz> *disassembly

13:44 <sj0rz> but i might be missing some context here

13:44 <fche> it's probably hard to do robustly, esp. with ever more cleverer compilers & assembelrs

13:45 <sj0rz> fair point

16:19 <irker079> systemtap: dsmith systemtap.git:refs/heads/master * release-3.1-205-g55594da / runtime/linux/kprobes.c: Fix PR21859 by locking the module mutex. http://tinyurl.com/yb4j5dud

19:26 <gromero> Hi. I'm getting "ERROR: read fault [man error::fault] at 0x0000000000000108 (addr) near operator '@cast' at ./full.d:171:21" probably because I'm trying to deref a variable that at sometimes gets null. What's the correct way to avoid it in systemtap (something like if (p!=NULL) ... I guess?)

19:26 <gromero> line in question is: 171 p_regs_msr = @cast(prev_task, "task_struct", "kernel<linux/sched.h>")->thread->regs->msr

19:26 <fche> yeah, or try { ... } catch { ... }

19:27 <gromero> fche: ah! thanks!

19:27 <fche> righto

19:27 <fche> there are other possibilites in [man error::fault] (that's a man page!)

19:29 <gromero> yup, I did look at https://sourceware.org/systemtap/man/error::fault.7stap.html

19:30 <gromero> --skip-badvars stopped the crashes but stopped to work as intended...

19:30 <fche> that - or try/catch - won't make a faulting address work, just not fail that particular way

19:31 <fche> and yeah, first-principles checking if ($ptr->field != 0) also works

19:32 <gromero> ok. I think that in my case thread->regs can be zero at some conditions (maybe on new create and scheduled task...)

19:32 <gromero> s/zero/NULL/

19:33 <fche> could be. stap cannot lock the kernel structures while the script is traversing them, so race conditions can occur

19:33 <fche> so this is why stap protects itself with that read fault error

19:34 <gromero> hm interesting