linux-kernel - Re: [PATCH bpf-next v11 04/11] libbpf: Optimize type lookup with binary search for sorted BTF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAErzpmu1-BwS29mBfsZ75wYh+8uveHA82dUQz+AzkLUFKKBn-g@mail.gmail.com>
Date: Thu, 8 Jan 2026 13:01:50 +0800
From: Donglin Peng <dolinux.peng@...il.com>
To: bot+bpf-ci@...nel.org
Cc: ast@...nel.org, andrii.nakryiko@...il.com, eddyz87@...il.com, 
	zhangxiaoqin@...omi.com, ihor.solodrai@...ux.dev, 
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org, pengdonglin@...omi.com, 
	alan.maguire@...cle.com, andrii@...nel.org, daniel@...earbox.net, 
	martin.lau@...nel.org, yonghong.song@...ux.dev, clm@...a.com
Subject: Re: [PATCH bpf-next v11 04/11] libbpf: Optimize type lookup with
 binary search for sorted BTF

On Thu, Jan 8, 2026 at 11:46 AM <bot+bpf-ci@...nel.org> wrote:
>
> > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> > index bf75f770d29a..60ff8eafea83 100644
> > --- a/tools/lib/bpf/btf.c
> > +++ b/tools/lib/bpf/btf.c
>
> [ ... ]
>
> > @@ -897,46 +899,83 @@ int btf__resolve_type(const struct btf *btf, __u32 type_id)
> >       return type_id;
> >  }
> >
> > -__s32 btf__find_by_name(const struct btf *btf, const char *type_name)
> > -{
> > -     __u32 i, nr_types = btf__type_cnt(btf);
> > -
> > -     if (!strcmp(type_name, "void"))
> > -             return 0;
> > -
> > -     for (i = 1; i < nr_types; i++) {
>                   ^
> The original btf__find_by_name() started iteration from ID 1, which meant
> it would search through ALL types including those in base BTF for split
> BTF scenarios. The btf__type_by_id() call would transparently access
> base BTF types when i < btf->start_id.
>
> > -             const struct btf_type *t = btf__type_by_id(btf, i);
> > -             const char *name = btf__name_by_offset(btf, t->name_off);
> > -
> > -             if (name && !strcmp(type_name, name))
> > -                     return i;
> > -     }
> > -
> > -     return libbpf_err(-ENOENT);
> > -}
>
> [ ... ]
>
> > +/* the kind value of -1 indicates that kind matching should be skipped */
> > +__s32 btf__find_by_name(const struct btf *btf, const char *type_name)
> > +{
> > +     return btf_find_by_name_kind(btf, btf->start_id, type_name, -1);
>                                         ^^^^^^^^^^^^^^^
> Is this intended to change the split BTF lookup behavior? The new

Thanks, my bad. We should pass 1, not btf->start_id.

> implementation passes btf->start_id as the start_id parameter, which
> means for split BTF the search will only cover types in the current BTF
> instance, not the base BTF.
>
> In btf_find_by_name_kind(), the base BTF is only searched when
> start_id < btf->start_id, but here start_id == btf->start_id so that
> condition is never true.
>
> Compare with btf__find_by_name_kind() which still passes 1 as start_id:
>
>   __s32 btf__find_by_name_kind(const struct btf *btf, ...)
>   {
>       return btf_find_by_name_kind(btf, 1, type_name, kind);
>   }
>
> This creates an inconsistency where btf__find_by_name_kind() searches
> base BTF but btf__find_by_name() does not. Was this behavior change
> intentional? If so, perhaps the commit message should mention it.
>
> > +}
> > +
> >  __s32 btf__find_by_name_kind_own(const struct btf *btf, const char *type_name,
> >                                __u32 kind)
> >  {
> >       return btf_find_by_name_kind(btf, btf->start_id, type_name, kind);
> >  }
>
> [ ... ]
>
>
> ---
> 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/20804442135