On Thu, Apr 2, 2026 at 2:13 PM Leon Hwang <[email protected]> wrote: > > On Tue, Nov 18, 2025 at 08:36:28PM +0800, Menglong Dong wrote: > >For now, the bpf trampoline is called by the "call" instruction. However, > >it break the RSB and introduce extra overhead in x86_64 arch. > > [...] > > > >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 > > > >As we can see above, the RSB is totally balanced after this series. > > > > Hi, this is a late footnote for this optimization. > > As this optimization landed in the 6.19 kernel, the function graph feature > of bpfsnoop [1] cannot work because of the missing tracee's FP/IP for > fexit. > > Before this optimization, > > caller > -> call icmp_rcv caller IP/FP > -> call trampoline icmp_rcv IP/FP > -> call icmp_rcv body trampoline IP/FP > <- return to trampoline > <- return to caller > > After this optimization, > > caller > -> call icmp_rcv caller IP/FP > -> jump to trampoline > -> call icmp_rcv body trampoline IP/FP > <- return to trampoline > <- return to caller
Ah, you are right. The target symbol will disappear in the stack backtrace in BPF prog, as we jump to the trampoline directly. We can pretend a RIP in the stack for the address of the "function body", therefore the target symbol can show in the stack backtrace. I have not tried it yet, but I think it should work. However, I'm not sure if it is worth it. Thanks! Menglong Dong > > As a result, the function call stack entry for icmp_rcv has gone. > > It can be confirmed by bpf_get_stack*() helpers. > > $ sudo bpfsnoop -k icmp_rcv --output-stack -v > > In 6.14, > > 0xffff8000802bda44:bpfsnoop_fn+0x6a4 > 0xffff8000802bda44:bpfsnoop_fn+0x6a4 > 0xffff8000802bd064:bpf_trampoline_6442573163+0xa4 > 0xffffc7825c984df0:icmp_rcv+0x8 > 0xffffc7825c91bcb8:ip_protocol_deliver_rcu+0x48 > 0xffffc7825c91bfd4:ip_local_deliver_finish+0x8c > 0xffffc7825c91c0d0:ip_local_deliver+0x88 > > In 6.19, > > 0xffffffffc0209069:bpfsnoop_fn+0x449 > 0xffffffffc01ef2a4:bpf_trampoline_6442568724+0x64 > 0xffffffffb1085cda:ip_protocol_deliver_rcu+0x1ea > 0xffffffffb1085d96:ip_local_deliver_finish+0x86 > 0xffffffffb1085e95:ip_local_deliver+0x65 > > So, it would surprise users who care about the tracee entry. > > [1] https://github.com/bpfsnoop/bpfsnoop > > Thanks, > Leon > > [...]
