Re: [PATCH 2/2] powerpc/text-patching: Fix possible stringop-overread compilation error

On Thu, Feb 05, 2026 at 06:05:17PM +0800, Xie Yuanbin wrote:

First of all, when sending a series, always add a cover letter to explain
dependencies, goal, and how to route the series via the respective tree(s),
et cetera.

For strnlen(), if the compiler detects that the maxlen argument exceeds
the valid memory size of the input string object, a compilation error may
occur.

For lastest linux-next source, changing ppc_kallsyms_lookup_name() to
__always_inline,

So, there is no issue in upstream without the mentioned change, right?

using default ppc64_defconfig, and setting
CONFIG_EXPERT=y, CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2=n,
CONFIG_CC_OPTIMIZE_FOR_SIZE=y. Then, when using gcc-15 for compilation,
the following error will be triggered:

  CC      arch/powerpc/kernel/optprobes.o
In file included from ./arch/powerpc/include/asm/kprobes.h:24,
                 from ./include/linux/kprobes.h:31,
                 from arch/powerpc/kernel/optprobes.c:8:
In function ‘ppc_kallsyms_lookup_name’,
    inlined from ‘arch_prepare_optimized_kprobe’ at arch/powerpc/kernel/optprobes.c:209:21:
./arch/powerpc/include/asm/text-patching.h:232:13: error: ‘strnlen’ specified bound 512 exceeds source size 19 [-Werror=stringop-overread]
  232 |         if (strnlen(name, KSYM_NAME_LEN) >= KSYM_NAME_LEN)
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘ppc_kallsyms_lookup_name’,
    inlined from ‘arch_prepare_optimized_kprobe’ at arch/powerpc/kernel/optprobes.c:210:22:
./arch/powerpc/include/asm/text-patching.h:232:13: error: ‘strnlen’ specified bound 512 exceeds source size 13 [-Werror=stringop-overread]
  232 |         if (strnlen(name, KSYM_NAME_LEN) >= KSYM_NAME_LEN)
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Refer to the implementation of fortify's strnlen(). If the string length
is a compile-time constant, do not call the strnlen() function.

I don't with the first patch this is a correct approach.
But I let others to comment, I assume Kees knows better
what's this and how it can be fixed without exporting
special macros.

-- 
With Best Regards,
Andy Shevchenko