Hi Andy, > Date: 2026-11-13 16:25:35+0200 > From: Andy Shevchenko > > On Fri, Nov 13, 2026 at 02:48:01PM +0100, Alejandro Colomar wrote: > > ... > > > > [Severity: Low] > > > Does moving str_has_prefix() out-of-line into lib/string.c bypass > > > CONFIG_FORTIFY_SOURCE and prevent compile-time constant folding of > > > strlen(prefix)? > > > > Preventing the compile-time constant folding of strlen(3) is indeed > > a performance degradation, but that's necessary to be able to > > WARN_ON_ONCE(), so there isn't anything we can do. > > > > > lib/string.c is built with __NO_FORTIFY and its top-of-file comment notes > > > that it is reserved for routines that have architecture-specific > > > alternatives in or get overloaded by FORTIFY_SOURCE, while > > > other helpers belong in lib/string_helpers.c. > > > > Do we want to move it to "lib/string_helpers.c"? I don't know enough > > about the organization in these files, so just let me know what I should > > do. > > string library (generic) is for broad use, so it should really be clean from > kernel things. string_helpers is exactly for some custom abstractions we use > in kernel. Now you should answer these questions (or more than that): > - Are there or potentially be users that needs this API earlier at the boot? > - Is this API is detached from the rest of string library semantically? > I.o.w. can we group semantically coupled APIs and consider them as a bundle? > - Due to the above, ask the first Q against semantically grouped APIs. > > My personal feeling that what you are trying to do is no go for generic string > as is. If you confirm that these APIs are not used / needed at early stages at > boot, they can be moved completely to string_helpers. Thanks! I guess I'll just drop the addition of WARN_ON_ONCE(). Let's leave the function as is, and document its problems. It's not worth the effort. After all, I think it's a bad function, and should not be used in new code. Have a lovely day! Alex > > -- > With Best Regards, > Andy Shevchenko > > --