On Wed, Sep 30, 2026 at 04:21:21PM +0200, Jason A. Donenfeld wrote: > 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: > > > 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. > > 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.
Nathan, would this be okay with you? https://git.zx2c4.com/linux-rng/commit/?id=d216701724b7d8209ff42150658ad5c712bdb503
