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

[bot+bpf-ci]

> 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?

[ ... ]


---
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