On 2025/11/14 21:38, Steven Rostedt wrote: > On Fri, 14 Nov 2025 17:24:43 +0800 > Menglong Dong <[email protected]> wrote: > > > Therefore, we introduce the "jmp" mode for bpf trampoline, as advised by > > Alexei in [1]. And the logic will become this: > > call foo -> jmp trampoline -> call foo-body -> > > return foo-body -> return foo > > This obviously only works when there's a single function used by that > trampoline. It also doesn't allow tracing of the return side (it's > basically just the function tracer for a single function).
Hi, Steven. I think you misunderstand something? For the fentry/fexit, the whole process is: call foo -> jmp trampoline -> call all the fentry bpf progs -> call foo-body -> return foo-body -> call all the fexit bpf progs -> return foo. The "call foo-body" means "origin call", and it will store the return value of the traced function to the stack, therefore the fexit progs can get it. So it can trace the return side with the "fexit". And it's almost the same as the origin logic of the bpf trampoline: call foo -> call trampoline -> call all the fentry bpf progs -> call foo-body -> return foo-body -> call all the fexit bpf progs -> skip the rip -> return foo. What I did here is just replace the "call trampoline" to "jmp trampoline". > > Is there any mechanism to make sure that the trampoline being called is > only used by that one function? I haven't looked at the code yet, but > should there be a test that makes sure a trampoline isn't registered for > two or more different functions? As for now, the bpf trampoline is per-function. Every trampoline has a unique key, and we find the trampoline for the target function by that key. So it can't be used by two or more different functions. If the trampoline need to get the ip of the origin call from the stack, such as BPF_TRAMP_F_SHARE_IPMODIFY case, we will fallback to the "call" mode, as we can't get the rip from the stack in the "jmp" mode. And I think this is what you mean "only work for a single function"? Yeah, we fallback on such case. Thanks! Menglong Dong > > -- Steve > >
