Re: [RFC bpf-next 04/12] bpf: Add struct bpf_tramp_node object

[Jiri Olsa <olsajiri@gmail.com>]

On Wed, Feb 04, 2026 at 11:00:57AM -0800, Andrii Nakryiko wrote:
> On Tue, Feb 3, 2026 at 1:39 AM Jiri Olsa <jolsa@kernel.org> 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

> 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 <jolsa@kernel.org>
> > ---
> >  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(-)
> >
> 
> [...]