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

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: <CAErzpmuaRop+Sg84WW_h9hL-fbOHwxqd0BuNQQRSSxu1TJnPLg@mail.gmail.com>
Date: Thu, 18 Dec 2025 17:16:15 +0800
From: Donglin Peng <dolinux.peng@...il.com>
To: Eduard Zingerman <eddyz87@...il.com>
Cc: ast@...nel.org, andrii.nakryiko@...il.com, zhangxiaoqin@...omi.com, 
	ihor.solodrai@...ux.dev, linux-kernel@...r.kernel.org, bpf@...r.kernel.org, 
	pengdonglin <pengdonglin@...omi.com>, Alan Maguire <alan.maguire@...cle.com>
Subject: Re: [PATCH bpf-next v9 08/10] bpf: Skip anonymous types in type
 lookup for performance

On Thu, Dec 18, 2025 at 1:29 AM Eduard Zingerman <eddyz87@...il.com> wrote:
>
> On Wed, 2025-12-17 at 17:21 +0800, Donglin Peng wrote:
> > On Wed, Dec 17, 2025 at 2:55 PM Eduard Zingerman <eddyz87@...il.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?

Thanks. I found that RHEL supports loading a kernel module between
different kernel versions with stable KABI. So I think we should not reject
loading modules with unsorted BTFs.