random: vDSO: Avoid call to memset() when zeroing reserved in __cvdso_getrandom_data()HEADmaster

After a recent change in LLVM [1], builds with the random vDSO
implementation, such as PowerPC and RISC-V, fail when checking the vDSO:

  arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported
  arch/riscv/kernel/vdso/vdso.so.dbg: dynamic relocations are not supported

memset() is now generated when zeroing params->reserved for some builds
because LLVM has an optimization (now run in more instances) that can
recognize at compile time when it is assigning a static value to a
contiguous area of memory and turn that into a call to memset(). Both
clang and GCC assume memset() is always available [2].

clang provides a builtin, __builtin_memset_inline [3][4], that can be
used to ensure an external function call is not generated when zeroing
this memory. Use it when it is available.

While GCC has no issues with the current code, it has generated memset()
before, as seen in commit b7bad082e113 ("random: vDSO: avoid call to out
of line memset()"). GCC 14 provides '-finline-stringops=memset' [5][6]
with a similar guarantee to the clang builtin, so use it and
__builtin_memset() when available.

If no option is available, provide a simple memset_inline() like the one
from lib/string.c to avoid adding an ugly ifdef.

Link: https://github.com/llvm/llvm-project/commit/90cebef1411617fc3eedd359bdf00cb44b1c2439 [1]
Link: https://gcc.gnu.org/onlinedocs/gcc-16.2.0/gcc/Standards.html#index-ffreestanding [2]
Link: https://github.com/llvm/llvm-project/commit/38637ee477541370a90b37f149069d8e5c0c2efd [3]
Link: https://clang.llvm.org/docs/LanguageExtensions.html#guaranteed-inlined-memset [4]
Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1ff6d9f7428b0668cd8ab0b3e3ab94f1d733124d [5]
Link: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-finline-stringops [6]
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: stable@vger.kernel.org # v6.12+
Closes: https://github.com/ClangBuiltLinux/linux/issues/2183
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

0 files changed, 0 insertions, 0 deletions