On Thu, Feb 05, 2026 at 02:27:38PM -0800, Andrii Nakryiko wrote: > On Thu, Feb 5, 2026 at 12:57 AM Jiri Olsa <[email protected]> wrote: > > > > On Wed, Feb 04, 2026 at 11:00:57AM -0800, Andrii Nakryiko wrote: > > > On Tue, Feb 3, 2026 at 1:39 AM Jiri Olsa <[email protected]> wrote: > > > > > > > > Adding struct bpf_tramp_node to decouple the link out of the trampoline > > > > attachment info. > > > > > > > > At the moment the object for attaching bpf program to the trampoline is > > > > 'struct bpf_tramp_link': > > > > > > > > struct bpf_tramp_link { > > > > struct bpf_link link; > > > > struct hlist_node tramp_hlist; > > > > u64 cookie; > > > > } > > > > > > > > The link holds the bpf_prog pointer and forces one link - one program > > > > binding logic. In following changes we want to attach program to > > > > multiple > > > > trampolines but have just one bpf_link object. > > > > > > > > Splitting struct bpf_tramp_link into: > > > > > > > > struct bpf_tramp_link { > > > > struct bpf_link link; > > > > struct bpf_tramp_node node; > > > > }; > > > > > > > > struct bpf_tramp_node { > > > > struct hlist_node tramp_hlist; > > > > struct bpf_prog *prog; > > > > u64 cookie; > > > > }; > > > > > > I'm a bit confused here. For singular fentry/fexit attachment we have > > > one trampoline and one program, right? For multi-fentry, we have > > > multiple trampoline, but still one program pointer, no? So why put a > > > prog pointer into tramp_node?.. You do want cookie in tramp_node, yes, > > > but not the program. > > > > yes, but both links: > > - single link 'struct bpf_tramp_link' > > - multi link 'struct bpf_tracing_multi_link' > > > > are using same code to attach that code needs to have a hlist_node to > > link the program to the trampoline and be able to reach the bpf_prog > > (like in invoke_bpf_prog) > > > > current code is passing whole bpf_tramp_link object so it has access > > to both, but multi link needs to keep link to each trampoline (nodes > > below): > > > > struct bpf_tracing_multi_link { > > struct bpf_link link; > > enum bpf_attach_type attach_type; > > int nodes_cnt; > > struct bpf_tracing_multi_node nodes[] __counted_by(nodes_cnt); > > }; > > > > and we can't get get from &nodes[x] to bpf_tracing_multi_link.link.prog > > > > it's bit redundant, but not sure what else we can do > > invoke_bpf_prog() specifically doesn't have to get prog pointer from > bpf_tramp_link, it can be passed prog as a separate argument and then > bpf_tramp_node with cookie separately as well. I haven't looked at > all other code, but I suspect we can refactor it to accept prog > explicitly and the relevant parts (node+cookie) separately.
ok, makes sense.. will check on how to refactor that code for some reason I thought we don't wan't to refactor jit code much, because it means changes through all the archs code.. but this one should mostly change just arguments, so it's probably ok > > Just at the conceptual level, we have single prog and multiple places > to patch (trampolines), so we shouldn't be co-locating in the same > data structure. It feels like a complete hack to duplicate prog just > to make some internal code access it. ook jirka
