On Fri, Feb 20, 2026 at 10:58:00AM +0000, [email protected] wrote: > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > > --- a/include/linux/bpf.h > > +++ b/include/linux/bpf.h > > [ ... ] > > > +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=xbkejdugco...@mail.gmail.com/ > > 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?
yep, I ended up with different change and mentioned it in the cover letter, I'm open to discus different solution if it's needed jirka > > > --- > 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.
