From: Nathan Chancellor <nathan@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@kernel.org>, Theodore Ts'o <tytso@mit.edu>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] random: vDSO: Avoid call to memset() when zeroing reserved in __cvdso_getrandom_data()
Date: Wed, 16 Sep 2026 15:57:00 -0700 [thread overview]
Message-ID: <20260916225700.GA4107307@ax162> (raw)
In-Reply-To: <CAKwvOdmnfkra0N34v5w8qh+8bb4X5AxLTtOULu46S8q9KCvzMQ@mail.gmail.com>
On Wed, Sep 16, 2026 at 03:08:38PM -0700, Nick Desaulniers wrote:
> Link: https://github.com/ClangBuiltLinux/linux/issues/2183
Whoops :/ thanks for including this
> Do we need to tag stable (I imagine this might be visible for older
> kernels with newer llvm)?
Yeah, we probably do, as I expect this error to happen with 6.16+ due to
commit ee0d03053e70 ("RISC-V: vDSO: Wire up getrandom() vDSO
implementation").
I will include those in v2 once the maintainers have had some time to
chime in to make sure this approach is okay.
> Any idea why we only see this for riscv? Would think loop idiom
> recognition would make this transform for any target.
I have not confirmed this but based on looking at the aarch64
disassembly when deciding how to tackle this, I suspect some backends
can expand certain calls to memset() to a set of instructions, as I saw
a set of stp calls with xzr as the source and offsets into params as the
dest.
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Thanks for taking a look!
--
Cheers,
Nathan
next prev parent reply other threads:[~2026-09-16 22:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 21:58 [PATCH] random: vDSO: Avoid call to memset() when zeroing reserved in __cvdso_getrandom_data() Nathan Chancellor
2026-09-16 22:08 ` Nick Desaulniers
2026-09-16 22:57 ` Nathan Chancellor [this message]
2026-09-16 23:40 ` Nick Desaulniers
2026-09-17 9:26 ` Jason A. Donenfeld
2026-09-17 17:39 ` Nathan Chancellor
2026-09-17 22:49 ` Nick Desaulniers
2026-09-18 8:20 ` Jason A. Donenfeld
2026-09-18 12:59 ` Jason A. Donenfeld
2026-09-18 19:19 ` Jason A. Donenfeld
2026-09-18 21:07 ` Nathan Chancellor
2026-09-19 10:57 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260916225700.GA4107307@ax162 \
--to=nathan@kernel.org \
--cc=Jason@zx2c4.com \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=luto@kernel.org \
--cc=morbo@google.com \
--cc=ndesaulniers@google.com \
--cc=tglx@kernel.org \
--cc=tytso@mit.edu \
--cc=vincenzo.frascino@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.