linux-kernel - Re: [PATCH v2 01/14] lib/string: extract generic strlen() into __generic

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: <CAHp75VenLXeWBjvjd6A2q6gepQdqkgGFzTMHZ-UY1s+4UHP14w@mail.gmail.com>
Date: Thu, 15 Jan 2026 08:55:19 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Feng Jiang <jiangfeng@...inos.cn>
Cc: David Laight <david.laight.linux@...il.com>, Eric Biggers <ebiggers@...nel.org>, pjw@...nel.org, 
	palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr, kees@...nel.org, 
	andy@...nel.org, akpm@...ux-foundation.org, martin.petersen@...cle.com, 
	ardb@...nel.org, ajones@...tanamicro.com, conor.dooley@...rochip.com, 
	samuel.holland@...ive.com, linus.walleij@...aro.org, nathan@...nel.org, 
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 01/14] lib/string: extract generic strlen() into __generic_strlen()

On Thu, Jan 15, 2026 at 8:51 AM Feng Jiang <jiangfeng@...inos.cn> wrote:
> On 2026/1/14 18:10, David Laight wrote:
> > On Tue, 13 Jan 2026 16:01:51 -0800
> > Eric Biggers <ebiggers@...nel.org> wrote:

...

> >> A similar problem exists with the architecture-optimized CRC and crypto
> >> functions.  Historically, these subsystems exported both generic and
> >> architecture-optimized functions.
> >>
> >> We've actually been moving away from that design to simplify things.
> >> For example, for CRC-32C there's now just the crc32c() function which
> >> delegates to the "best" CRC-32C implementation, with no direct access to
> >> the generic implementation of CRC-32C.
> >>
> >> crc_kunit then just tests and benchmarks crc32c().  To check how the
> >> performance of crc32c() changes when its implementation changes (whether
> >> the change is the addition of an arch-optimized implementation or a
> >> change in an existing arch-optimized implementation), the developer just
> >> needs to run crc_kunit with two kernels, before and after.
> >
> > For the mul_div tests I arranged that the test code could #include the
> > source for the generic implementation so it could run that as well as
> > the version compiled into the main kernel.
> >
> > This involved wrapping the function in:
> > #if !defined(function) || defined(test_function)
> > type function(args)
> > ...
> > }
> > #if !defined(function)
> > EXPORT_SYMBOL(function)
> > #endif
> > #endif
> >
> > So the test code can use:
> > #define function generic_function
> > #define test_function
> > #include "function.c"
> >
> > to get a private copy of the generic code.
>
> Thank you for the suggestion! That technique is very clever and interesting—
> I've definitely learned something new and will keep it in mind for the future.
>
> However, since lib/string.c is such a foundational and low-level library, I'm
> hesitant to add macro wrappers or conditional blocks for KUnit. Given its
> importance, I feel that increasing its complexity for side-by-side testing
> isn't quite worth it. I'd prefer to keep the core code clean and follow Eric's
> minimalist approach of benchmarking across different kernel configurations.
>
> I really appreciate the guidance!

I second you, we currently may stick with what Eric proposed and
consider other approaches in the future where appropriate.

-- 
With Best Regards,
Andy Shevchenko