Re: Re: [PATCH bpf-next v3 1/2] bpf: Support multi-level pointer params via SCALAR_VALUE for trampolines

[Alexei Starovoitov]

On Mon, Feb 23, 2026 at 2:48 AM Slava Imameev
<slava.imameev@xxxxxxxxxxxxxxx> wrote:
>
> I think support for broader types can be provided in a compatible way
> with future annotated support, as I explained in my reply to the v2
> review:
>
> "
>   > so I suggest treating 'void **' as a scalar as Eduard suggested.
>   > This particular sb_eat_lsm_opts() hook
>   > doesn't have a useful type behind it anyway.
>   > I'm less certain about 'char **'. If we make it scalar too
>   > it will be harder to make it a pointer to nul terminated string later.
>
>   > So I would do 'void **' -> scalar for now only.
>
>   I changed to scalar in v3, keeping broader scope for pointer types.
>
>   We encountered double pointers of various types that required
>   workarounds, such as:
>
>   int __posix_acl_chmod(struct posix_acl **acl, gfp_t gfp, umode_t mode)
>
>   Adding support for void** alone doesn't address the broader issue
>   with other double pointer types.
>
>   When annotated array support (including char**) is added in the
>   future, it should remain compatible with the scalar approach for
>   legacy (unannotated) parameters. Unannotated parameters will
>   continue using scalar handling.
> "

but then there is no need to relax it for double pointers only.

-       if (is_void_or_int_ptr(btf, t))
+       if (is_void_or_int_ptr(btf, t) || !btf_type_is_struct_ptr(btf, t))

would make 'scalar' a fallback for anything unrecognized,
and we can argue that making it smarter in the future
maybe hopefully won't break progs.