Re: [PATCH v2] random: vDSO: Avoid call to memset() when zeroing reserved in __cvdso_getrandom_data()

On Wed, Sep 30, 2026 at 03:38:13PM +0200, Nathan Chancellor wrote:

On Tue, Sep 29, 2026 at 11:24:11AM -0700, Nick Desaulniers wrote:

quoted

arch/arm64/kvm/hyp/nvhe/Makefile has this pattern for exactly the same
problem I suspect.  Maybe that's the right tool in the toolbox?

diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile
index 8dbf2532a573..27fa72d8fb86 100644
--- a/arch/riscv/kernel/vdso/Makefile
+++ b/arch/riscv/kernel/vdso/Makefile
@@ -27,7 +27,7 @@ asflags-y += -DVDSO_CFI=1
 endif

 # Files to link into the vdso
-obj-vdso = $(patsubst %, %.o, $(vdso-syms)) note.o
+obj-vdso = $(patsubst %, %.o, $(vdso-syms)) note.o ../../lib/memset.o

 ifdef CONFIG_VDSO_GETRANDOM
 obj-vdso += vgetrandom-chacha.o

Fixes `make -skj"$(nproc)" ARCH=riscv LLVM=1 mrproper allmodconfig
vdso_prepare` for me, as per

For the record, this also happens with the 32-bit PowerPC vDSO, as I
noted in the commit message of v2. I should update the issue too, I only
realized this after wider testing. So if this is the route we want to
go, we would need a memset() for that vDSO as well.

quoted

https://github.com/ClangBuiltLinux/linux/issues/2183
(Nathan, don't forget to link to that in the commit message)

Yes, thanks, I have added it for v3.

quoted

I'm surprised I didn't need -fno-semantic-interposition (or one of the
related flags... -fvisibility=hidden)

If we want to get better, (if performance matters here and we want to
trade source+build system complexity for absolute code perf) I would
start with that, then worry about clawing back performance via things
like:
- __builtin_memset_inline
- -finline-stringops=memset
- -ffunction-sections+-Wl,--gc-sections to dead code eliminate the out
of line copy of memset, though IIRC there's potential for wasted space
due to alignment requirements (maybe the out of line copy of memset is
smaller...idk)

Yeah, I guess it is ultimately up to the maintainers what route they
prefer.

I think linking in an out-of-line memset.o is not appealing. This isn't
a general library or something. So let's just go with your v2 approach,
fixed up in the ways we mentioned.