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

[Nathan Chancellor <nathan@kernel.org>]

On Tue, Sep 29, 2026 at 11:24:11AM -0700, Nick Desaulniers wrote:
> 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.

> 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.

> 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.

-- 
Cheers,
Nathan