[PATCH v2] random: vDSO: Avoid call to memset() when zeroing reserved in __cvdso_getrandom_data()
Nathan Chancellor
nathan at kernel.org
Thu Oct 1 04:03:10 PDT 2026
On Thu, Oct 01, 2026 at 12:48:10PM +0200, Jason A. Donenfeld wrote:
> On Thu, Oct 01, 2026 at 12:20:59PM +0200, Nathan Chancellor wrote:
> > control. The change that introduced -max-store-memset only did it to
> > "allow fine-tuning of the inlining threshold for performance analysis
> > and optimization". If they decide to remove it for whatever reason,
> > we're back to square one.
>
> I suppose all the more reason to get -finline-stringops=memset added to
> clang. Then the dual-default thing you came up with below will naturally
> start choosing the first option when it becomes available.
Fair point, I can file an issue with LLVM upstream.
> > I know something like below would be uglier due to the ifdef but it
> > would avoid changing anything for GCC while clearing up the issue at
> > hand for clang in a guaranteed stable and succinct manner.
>
> But then we're back to the byte-by-byte codegen that Christophe pointed
> out.
I thought that was only because the fallback memset_inline() from v2 was
doing a byte-by-byte initialization? With my suggested diff, nothing
should change for GCC, as it does not have __builtin_memset_inline(), so
the "Before the patch" code generation that Christophe showed should
still be present.
> > If that is not acceptable, something like the following does appear to
> > work for me.
>
> Okay, great, let's do that.
>
> Does this commit seem okay with you? I used the diff you sent below and
> adjusted the commit message: https://git.zx2c4.com/linux-rng/commit/?id=56ff95ee85715047eb5b5220243778af657778c8
Yeah, that seems fine to me, thanks for taking care of it!
--
Cheers,
Nathan
More information about the linux-riscv
mailing list