01:03 <agentzh> fche kerneltoast: happy deadlock hunting! it's fun to see you two watch each other like in a 1989 office :)

01:06 <agentzh> kerneltoast: happy thanksgiving, btw.

01:12 <agentzh> lindi-: i think the crash utility is still the easiest way. i agree it's far from perfect. got better suggestions?

02:27 <kerneltoast> agentzh, the stap bugs never end :P

02:28 <kerneltoast> i'll be happily thinking of less painful things during thanksgiving :)

02:28 <fche> oh they are tasty and delicious bugs

02:28 <fche> they will make the world wonderful

02:28 <fche> and stuff

05:21 <kerneltoast> can i get gravy with those bugs?

07:45 <agentzh> fche: any quick hack to make re2c support perl-compatible regexes? wondering if there's some magic flag to turn on...

11:17 <fche> agentzh, no magic flag

11:18 <fche> our regex engine works by compilation too, so not a simple matter

11:21 <ema> fche: I have a very dumb question!

11:22 <ema> what's the value of pid() in the context of probes like kernel.function("tcp_try_fastopen") ?

11:23 <fche> whatever task is running at that moment on that cpu

11:23 <fche> depending on the kernel function, it could be an action directly caused by a syscall from that userspace process, so its pid then

11:23 <fche> or it could be an interrupt handler, in which case it could be anything, or 0

11:23 <ema> excellent, and is there a way to distinguish between the two?

11:24 <ema> because in the syscall case it does make sense to know pid(), but in the example of an interrupt not really

12:52 <fche> ema,

12:53 <fche> no obvious way from a systemtap perspective, because when it comes to probing the kernel, we/it cannot know whether any particular piece of the kernel can only execute in proper user context or not

13:36 <ema> fche: fair enough, it should often be clear to the user by looking at a backtrace and seeing if it includes stuff like do_syscall vs do_softirq probably

13:55 <fche> yeha

13:55 <fche> and if you're probing syscall.* e.g., it's obvious