On Sun, Aug 9, 2020 at 8:10 PM <[email protected]> wrote: > > On Fri, Aug 7, 2020 at 11:31 AM, Andrii Nakryiko wrote: > > You can't do it reliably with kretprobe. kretprobe is executed right > before the function is exiting, by that time all the registers that > contained input parameters could have been used for something else. So > you got lucky with struct sock * here, but as a general rule you > shouldn't rely on this. You either have to pair kprobe with kretprobe > and store input arguments, or take a look at fexit program type, it is > just like kretprobe, but faster and guarantees input arguments are > preserved. > > Thanks for reply. > It seems fexit it a new feature and I'm using linux v4.15, so fexit can't > help here. > kretprobe with kprobe is an option and I've found a lot examples in bbc, but > I am also wondering if it is always right to use pid_tgid as key to store > params and get it from kretprobe. > I am wondering if there is a chance that following case would happen: > > 0. attach kprobe program in tcp_set_state, store params in HASHMAP using > pid_tgid as key; attach kretprobe in tcp_set_state, lookup params using > pid_tgid > 1. kprobe program triggered twice with same pid_tgid before kretprobe > executed, so can only get the last params > > I have this concern because I'm using golang and the two goroutines may map > to one thread in kernel. If one goroutine gets interrupted when executing > tcp_set_state, another one would have a chance to execute tcp_set_state with > the same pid_tgid.
I don't think golang can interrupt thread while it's being executed in the kernel. So from the golang perspective I wouldn't worry, the kernel will execute both kprobe and corresponding kretprobe before golang runtime can do anything about that. But in general, it's possible to attach kprobe to a kernel function that could be called multiple times for a given thread, at which point pid_tgid won't be enough. This cannot happen for syscalls and many other kernel functions, though. I would imagine that's not the case for tcp_set_state either. But please double check kernel sources to be absolutely sure. > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1889): https://lists.iovisor.org/g/iovisor-dev/message/1889 Mute This Topic: https://lists.iovisor.org/mt/76044869/21656 Mute #pragma: https://lists.iovisor.org/g/iovisor+iovisor-dev/mutehashtag/pragma Mute #bcc: https://lists.iovisor.org/g/iovisor+iovisor-dev/mutehashtag/bcc Group Owner: [email protected] Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
