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.
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.
>
> > Because then there is also a question what is
> > bpf_link's prog pointing to?...
>
> bpf_link.prog is still keeping the prog, I don't think we can remove that
>
> jirka
>
> >
> >
> > >
> > > where 'struct bpf_tramp_link' defines standard single trampoline link,
> > > and 'struct bpf_tramp_node' is the attachment trampoline object. This
> > > will allow us to define link for multiple trampolines, like:
> > >
> > > struct bpf_tracing_multi_link {
> > > struct bpf_link link;
> > > ...
> > > int nodes_cnt;
> > > struct bpf_tracing_multi_node nodes[] __counted_by(nodes_cnt);
> > > };
> > >
> > > Signed-off-by: Jiri Olsa <[email protected]>
> > > ---
> > > arch/arm64/net/bpf_jit_comp.c | 58 +++++++++----------
> > > arch/s390/net/bpf_jit_comp.c | 42 +++++++-------
> > > arch/x86/net/bpf_jit_comp.c | 54 ++++++++---------
> > > include/linux/bpf.h | 47 ++++++++-------
> > > kernel/bpf/bpf_struct_ops.c | 24 ++++----
> > > kernel/bpf/syscall.c | 25 ++++----
> > > kernel/bpf/trampoline.c | 102 ++++++++++++++++-----------------
> > > net/bpf/bpf_dummy_struct_ops.c | 11 ++--
> > > 8 files changed, 185 insertions(+), 178 deletions(-)
> > >
> >
> > [...]
