linux-kernel - Re: [RFC PATCH v4 1/7] libbpf: Extract BTF type remapping logic into helper function

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: <7f3586157e17d0ab2c34b16d2f7daf4955d0692f.camel@gmail.com>
Date: Wed, 05 Nov 2025 11:41:02 -0800
From: Eduard Zingerman <eddyz87@...il.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Donglin Peng <dolinux.peng@...il.com>, ast@...nel.org, 
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org, Alan Maguire
	 <alan.maguire@...cle.com>, Song Liu <song@...nel.org>, pengdonglin
	 <pengdonglin@...omi.com>
Subject: Re: [RFC PATCH v4 1/7] libbpf: Extract BTF type remapping logic
 into helper function

On Wed, 2025-11-05 at 10:20 -0800, Andrii Nakryiko wrote:

[...]

> You don't like that I ask people to improve implementation?

Not at all.

> You don't like the implementation itself? Or are you suggesting that
> we should add a "generic" C implementation of
> lower_bound/upper_bound and use callbacks for comparison logic? What
> are you ranting about, exactly?

Actually, having it as a static inline function in a header would be
nice. I just tried that, and gcc is perfectly capable of inlining the
comparison function in -O2 mode.

I'm ranting about patch #5 being 101 insertions(+), 10 deletions(-)
and patch #4 being 119 insertions(+), 23 deletions(-),
while doing exactly the same thing.

And yes, this copy of binary search routine probably won't ever
change. But changes to the comparator logic are pretty much possible,
if we decide to include 'kind' as a secondary key one day.
And that change will have to happen twice.

> As I said, once binary search (of whatever kind, bounds or exact) is
> written for something like this, it doesn't have to ever be modified.
> I don't see this as a maintainability hurdle at all. But sharing code
> between libbpf and kernel is something to be avoided. Look at #ifdef
> __KERNEL__ sections of relo_core.c as one reason why.