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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAEf4Bzb9Q3u-a0QCv=nTjdn_ufmfUh-hd-0N3dC=0NmjO6u8kw@mail.gmail.com>
Date: Thu, 6 Nov 2025 09:09:02 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Eduard Zingerman <eddyz87@...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, Nov 5, 2025 at 11:41 AM Eduard Zingerman <eddyz87@...il.com> wrote:
>
> 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 dislike callbacks in principle, but I don't mind having such a
reusable primitive, if it's reasonably abstracted. Do it.

>
> 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.

Understandable, but code reuse is not (at least it should not be) the
goal for its own sake. It should help manage complexity and improve
maintainability. Code sharing is not all pros, it creates unnecessary
entanglement and dependencies.

I don't think sharing this code between libbpf and kernel is justified
here. 100 lines of code is not a big deal, IMO.

>
> 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.