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
> 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(-)
> >
>
> [...]
