linux-kernel - Re: [RFC PATCH v2 1/5] btf: search local BTF before base 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <dacb24230861da2eb8fb5bd7168bdca571727b62.camel@gmail.com>
Date: Tue, 21 Oct 2025 08:56:01 -0700
From: Eduard Zingerman <eddyz87@...il.com>
To: Donglin Peng <dolinux.peng@...il.com>
Cc: ast@...nel.org, linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
 Andrii Nakryiko <andrii.nakryiko@...il.com>, Alan Maguire
 <alan.maguire@...cle.com>, Song Liu	 <song@...nel.org>, pengdonglin
 <pengdonglin@...omi.com>
Subject: Re: [RFC PATCH v2 1/5] btf: search local BTF before base BTF

On Tue, 2025-10-21 at 16:31 +0800, Donglin Peng wrote:
> On Tue, Oct 21, 2025 at 9:06 AM Eduard Zingerman <eddyz87@...il.com> wrote:
> > 
> > On Mon, 2025-10-20 at 17:39 +0800, Donglin Peng wrote:
> > > Change btf_find_by_name_kind() to search the local BTF first,
> > > then fall back to the base BTF. This can skip traversing the large
> > > vmlinux BTF when the target type resides in a kernel module's BTF,
> > > thereby significantly improving lookup performance.
> > > 
> > > In a test searching for the btf_type of function ext2_new_inode
> > > located in the ext2 kernel module:
> > > 
> > > Before: 408631 ns
> > > After:     499 ns
> > > 
> > > Performance improvement: ~819x faster
> > 
> > [...]
> > 
> > > ---
> > 
> > The flip makes sense, but are we sure that there are no implicit
> > expectations to return base type in case of a name conflict?
> > 
> > E.g. kernel/bpf/btf.c:btf_parse_struct_metas() takes a pointer to
> > `btf` instance and looks for types in alloc_obj_fields array by name
> > (e.g. "bpf_spin_lock"). This will get confused if module declares a
> > type with the same name. Probably not a problem in this particular
> > case, but did you inspect other uses?
> 
> Thank you for pointing this out. I haven't checked other use cases yet,
> and you're right that this could indeed become a real issue if there are
> name conflicts between local and base types. It seems difficult to
> prevent this behavior entirely. Do you have any suggestions on how we
> should handle such potential conflicts?

What are the results of the above benchmark after sorting?
If things are fast enough we might not need to do this change.
Otherwise, each call to btf_find_by_name_kind() should be
inspected. If necessary new APIs can be added to search only in
vmlinux, or only in program, or only in module BTF.