Re: [PATCH bpf-next 04/17] bpf: Add struct bpf_tramp_node object
From: bot+bpf-ci@kernel.org
Date: 2026-02-20 10:58:00
Also in:
bpf
quoted hunk ↗ jump to hunk
diff --git a/include/linux/bpf.h b/include/linux/bpf.h --- a/include/linux/bpf.h +++ b/include/linux/bpf.h
[ ... ]
quoted hunk ↗ jump to hunk
+struct bpf_tramp_node { + struct bpf_link *link; + struct hlist_node tramp_hlist; + u64 cookie; +};
During the RFC review, Andrii Nakryiko suggested that instead of
co-locating a prog/link pointer in bpf_tramp_node, the JIT functions
like invoke_bpf_prog() could accept the prog pointer as a separate
argument, keeping bpf_tramp_node to just {tramp_hlist, cookie}:
https://lore.kernel.org/bpf/CAEf4BzY=vqpnjrDNtLVvC3_nU5=Z7iROU_He=xbkEJDuGCoqug@mail.gmail.com/ (local)
The RFC had `struct bpf_prog *prog` in bpf_tramp_node and this v1
changed it to `struct bpf_link *link`, which still co-locates the
path to the program inside the node. Was the refactoring to pass
prog separately to invoke_bpf_prog() considered and ruled out, or
is that planned for a follow-up?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22220470181
AI-authorship-score: low
AI-authorship-explanation: Mechanical refactoring with lore history dating back to 2021, consistent with the author's known kernel development style and iterative review process.
issues-found: 1
issue-severity-score: low
issue-severity-explanation: Unaddressed RFC review comment from maintainer about struct design; not a code bug but a design concern about co-locating link pointer in bpf_tramp_node.