Re: [PATCH bpf v4 1/3] bpf: Wait for an RCU tasks grace period before freeing trampoline progs

[Florent Revest]

On Fri Sep 25, 2026 at 10:47 AM UTC,  wrote:
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 1d2676782d70..d4f732996b47 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -1770,6 +1770,7 @@ struct bpf_prog_aux {
> >  	bool offload_requested; /* Program is bound and offloaded to the netdev. */
> >  	bool attach_btf_trace; /* true if attaching to BTF-enabled raw tp */
> >  	bool attach_tracing_prog; /* true if tracing another tracing program */
> > +	bool tramp_linked; /* true if it was ever called from a trampoline */
> >  	bool func_proto_unreliable;
>
> Does this comment accurately describe when the flag is set?
>
> Looking at bpf_trampoline_add_prog() in kernel/bpf/trampoline.c, the
> flag is set at link time, right after hlist_add_head():
>
> 	hlist_add_head(&node->tramp_hlist, prog_list);
> 	node->link->prog->aux->tramp_linked = true;
>
> This happens before bpf_trampoline_update() has generated an image that
> could call the prog. If bpf_trampoline_update() then fails,
> __bpf_trampoline_link_prog() calls bpf_trampoline_remove_prog() and the
> flag stays true even though no trampoline ever called the prog.
>
> Setting the flag conservatively is correct for the free path, since it
> only adds an RCU Tasks grace period. But the comment describes a
> different condition than the one the code tracks. The field name and the
> commit message both say "linked to a trampoline".
>
> Would something like /* true if it was ever linked to a trampoline */
> match the code better, and stop a later reader from assuming the flag is
> only set once a trampoline image has actually run the prog?

Done in v5.

> [ ... ]
>
>
> ---
> 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/36122863248