Re: [PATCH bpf-next v9 08/10] bpf: Skip anonymous types in type lookup for performance

[Eduard Zingerman <eddyz87@gmail.com>]

On Wed, 2025-12-17 at 17:21 +0800, Donglin Peng wrote:
> On Wed, Dec 17, 2025 at 2:55 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
> > 
> > On Mon, 2025-12-08 at 14:23 +0800, Donglin Peng wrote:
> > 
> > [...]
> > 
> > > @@ -550,6 +550,11 @@ u32 btf_nr_types(const struct btf *btf)
> > >       return total;
> > >  }
> > > 
> > > +u32 btf_sorted_start_id(const struct btf *btf)
> > > +{
> > > +     return btf->sorted_start_id ?: (btf->start_id ?: 1);
> > > +}
> > > +
> > 
> > I think that changes in this patch are correct.  However, it seems
> 
> Thanks, I think the changes to btf_find_decl_tag_value and
> btf_prepare_func_args will cause issues if the input btf is a
> split BTF. We should search from its base BTF. Like this:
> 
> const struct btf *base_btf = btf;
> while (btf_base_btf(base_btf))
>         base_btf = btf_base_btf(base_btf);
> id = base_btf->sorted_start_id > 0 ? base_btf->sorted_start_id - 1 : 0;

Missed that, makes sense.

> > error prone to remember that sorted_start_id is always set for
> > vmlinux/module BTF and might not be set for program BTF.
> > Wdyt about using the above function everywhere instead of directly
> > reading the field?
> 
> Agreed. If so, I think we need to add another helper function to check
> whether the input BTF is sorted to improve code clarity.
> 
> bool btf_is_sorted(const struct btf *btf)
> {
>         return btf->sorted_start_id > 0;
> }

Sure, as you see fit.

> Besides, do you think we should reject loading a  kernel module that is
> not sorted?

Not my strong side. As far as I understand, when external modules are
built for production use-cases DKMS is used. DKMS will use same
resolve_btfids as the kernel module is built for. Hence reject the
modules with not sorted BTFs should be fine. Are there other use-cases
when mismatch between resolve_btfids versions is allowed?