> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 4764b4aa7081..bc5a57a9faee 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -2094,6 +2094,11 @@ static inline void
> bpf_prog_put_recursion_context(struct bpf_prog *prog)
> #endif
> }
>
> +static inline bool is_tracing_multi(enum bpf_attach_type type)
> +{
> + return type == BPF_TRACE_FENTRY_MULTI || type == BPF_TRACE_FEXIT_MULTI;
> +}
> +
> #if defined(CONFIG_BPF_JIT) && defined(CONFIG_BPF_SYSCALL)
> /* This macro helps developer to register a struct_ops type and generate
> * type information correctly. Developers should use this macro to register
[ ... ]
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index aec171ccb6ef..0cde0e2f3d4b 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -1155,6 +1155,8 @@ enum bpf_attach_type {
> BPF_TRACE_KPROBE_SESSION,
> BPF_TRACE_UPROBE_SESSION,
> BPF_TRACE_FSESSION,
> + BPF_TRACE_FENTRY_MULTI,
> + BPF_TRACE_FEXIT_MULTI,
> __MAX_BPF_ATTACH_TYPE
> };
>
[ ... ]
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 8ed484cb1a8a..521ec2a9051e 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
[ ... ]
> @@ -18699,6 +18701,11 @@ static int check_attach_modify_return(unsigned long
> addr, const char *func_name)
>
> #endif /* CONFIG_FUNCTION_ERROR_INJECTION */
>
> +static bool is_tracing_multi_id(const struct bpf_prog *prog, u32 btf_id)
> +{
> + return is_tracing_multi(prog->expected_attach_type) &&
> bpf_multi_func_btf_id[0] == btf_id;
> +}
> +
> int bpf_check_attach_target(struct bpf_verifier_log *log,
> const struct bpf_prog *prog,
> const struct bpf_prog *tgt_prog,
> @@ -18821,6 +18828,8 @@ int bpf_check_attach_target(struct bpf_verifier_log
> *log,
> prog_extension &&
> (tgt_prog->expected_attach_type == BPF_TRACE_FENTRY ||
> tgt_prog->expected_attach_type == BPF_TRACE_FEXIT ||
> + tgt_prog->expected_attach_type == BPF_TRACE_FENTRY_MULTI ||
> + tgt_prog->expected_attach_type == BPF_TRACE_FEXIT_MULTI ||
> tgt_prog->expected_attach_type == BPF_TRACE_FSESSION)) {
> /* Program extensions can extend all program types
> * except fentry/fexit. The reason is the following.
[ ... ]
> @@ -18956,7 +18967,18 @@ int bpf_check_attach_target(struct bpf_verifier_log
> *log,
> if (ret < 0)
> return ret;
>
> - if (tgt_prog) {
> + /*
> + * *.multi programs don't need an address during program
> + * verification, we just take the module ref if needed.
> + */
> + if (is_tracing_multi_id(prog, btf_id)) {
> + if (btf_is_module(btf)) {
> + mod = btf_try_get_module(btf);
> + if (!mod)
> + return -ENOENT;
> + }
> + addr = 0;
> + } else if (tgt_prog) {
> if (subprog == 0)
> addr = (long) tgt_prog->bpf_func;
> else
Should BPF_TRACE_FENTRY_MULTI and BPF_TRACE_FEXIT_MULTI be added to the
validation list in btf_validate_prog_ctx_type() in kernel/bpf/btf.c?
This concern was raised in v6 by [email protected] (message-id
23ab5817f619274a252b35119e760817c383e3c20f9ce9facccbf4b4fec9dd58
at mail.kernel.org, dated Wed, 27 May 2026):
"The multi types are not included in btf_validate_prog_ctx_type()
in kernel/bpf/btf.c. That function validates which attach types
allow u64* as their ctx parameter... Since BPF_TRACE_FENTRY_MULTI
and BPF_TRACE_FEXIT_MULTI also use u64* context, do they need to
be added to that validation list?"
The author acknowledged this in the v6 discussion but the change has
not been included in v7. Since these multi types use the same u64*
context layout as BPF_TRACE_FENTRY and BPF_TRACE_FEXIT, should they
be added alongside those types in btf_validate_prog_ctx_type()?
Lore reference:
https://lore.kernel.org/bpf/23ab5817f619274a252b35119e760817c383e3c20f9ce9facccbf4b4fec9d...@mail.kernel.org/
---
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/26881310426
