linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>,
	Ard Biesheuvel <ardb+git@google.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
	herbert@gondor.apana.org.au
Subject: Re: [PATCH v4 08/21] lib/crc: Switch ARM and arm64 to 'ksimd' scoped guard API
Date: Wed, 12 Nov 2025 12:58:32 -0800	[thread overview]
Message-ID: <20251112205832.GC1760@sol> (raw)
In-Reply-To: <CAMj1kXGog9bwqc=1qCv+Lh3giK081jf9h4AFCvQ=6Ls6N27LyA@mail.gmail.com>

On Tue, Nov 04, 2025 at 04:32:28PM +0100, Ard Biesheuvel wrote:
> On Mon, 3 Nov 2025 at 12:28, Jonathan Cameron
> <jonathan.cameron@huawei.com> wrote:
> >
> > On Fri, 31 Oct 2025 15:05:19 +0100
> > Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > > On Fri, 31 Oct 2025 at 14:52, Ard Biesheuvel <ardb@kernel.org> wrote:
> > > >
> > > > On Fri, 31 Oct 2025 at 14:49, Jonathan Cameron
> > > > <jonathan.cameron@huawei.com> wrote:
> > > > >
> > > > > On Fri, 31 Oct 2025 11:39:07 +0100
> > > > > Ard Biesheuvel <ardb+git@google.com> wrote:
> > > > >
> > > > > > From: Ard Biesheuvel <ardb@kernel.org>
> > > > > >
> > > > > > Before modifying the prototypes of kernel_neon_begin() and
> > > > > > kernel_neon_end() to accommodate kernel mode FP/SIMD state buffers
> > > > > > allocated on the stack, move arm64 to the new 'ksimd' scoped guard API,
> > > > > > which encapsulates the calls to those functions.
> > > > > >
> > > > > > For symmetry, do the same for 32-bit ARM too.
> > > > > >
> > > > > > Reviewed-by: Eric Biggers <ebiggers@kernel.org>
> > > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > > > > > ---
> > > > > >  lib/crc/arm/crc-t10dif.h   | 16 +++++-----------
> > > > > >  lib/crc/arm/crc32.h        | 11 ++++-------
> > > > > >  lib/crc/arm64/crc-t10dif.h | 16 +++++-----------
> > > > > >  lib/crc/arm64/crc32.h      | 16 ++++++----------
> > > > > >  4 files changed, 20 insertions(+), 39 deletions(-)
> > > > > >
> > > > > > diff --git a/lib/crc/arm/crc-t10dif.h b/lib/crc/arm/crc-t10dif.h
> > > > > > index 63441de5e3f1..aaeeab0defb5 100644
> > > > > > --- a/lib/crc/arm/crc-t10dif.h
> > > > > > +++ b/lib/crc/arm/crc-t10dif.h
> > > > >
> > > > > >  static __ro_after_init DEFINE_STATIC_KEY_FALSE(have_neon);
> > > > > > @@ -20,21 +19,16 @@ asmlinkage void crc_t10dif_pmull8(u16 init_crc, const u8 *buf, size_t len,
> > > > > >  static inline u16 crc_t10dif_arch(u16 crc, const u8 *data, size_t length)
> > > > > >  {
> > > > > >       if (length >= CRC_T10DIF_PMULL_CHUNK_SIZE) {
> > > > > > -             if (static_branch_likely(&have_pmull)) {
> > > > > > -                     if (likely(may_use_simd())) {
> > > > > > -                             kernel_neon_begin();
> > > > > > -                             crc = crc_t10dif_pmull64(crc, data, length);
> > > > > > -                             kernel_neon_end();
> > > > > > -                             return crc;
> > > > > > -                     }
> > > > > > +             if (static_branch_likely(&have_pmull) && likely(may_use_simd())) {
> > > > > > +                     scoped_ksimd()
> > > > > > +                             return crc_t10dif_pmull64(crc, data, length);
> > > > >
> > > > > >               } else if (length > CRC_T10DIF_PMULL_CHUNK_SIZE &&
> > > > > >                          static_branch_likely(&have_neon) &&
> > > > > >                          likely(may_use_simd())) {
> > > > >
> > > > > I briefly thought this was a functional change but it's not because
> > > > > of may_use_simd() being something that isn't going to change between
> > > > > the two evaluations.
> > > > >
> > > > > Would it hurt at all to pull that up to be
> > > > >         if (length >= CRC_T10DIF_PMULL_CHUNK_SIZE && likely(may_use_simd())) {
> > > > >                 if (static_branch_likely(&have_pmull)) {
> > > > >                         scoped_ksimd()
> > > > >                                 return crc_t10dif_pmull64(crc, data, length);
> > > > >
> > > > >                 } else if (length > CRC_T10DIF_PMULL_CHUNK_SIZE &&
> > > > >                            static_branch_likely(&have_neon)) {
> > > > >                 ...
> > > > >
> > > > > ?
> > > > >
> > > >
> > > > Yeah that would be a reasonable cleanup, I guess.
> > >
> > > Actually, looking more closely, that would result in may_use_simd()
> > > being evaluated even when the static keys are set to false, given that
> > > the compiler is unlikely to be able to figure out by itself that
> > > may_use_simd() has no side effects.
> > Yeah. That was why it was a question :)
> > Given everything is marked as likely I wasn't sure if we cared about when
> > the static keys aren't set.
> >
> 
> Yeah, it is rather doubtful that those annotations (or the use of
> static keys, for that matter) make a meaningful difference here.

Well, this change makes crc_t10dif_update() not usable during early boot
on arm64, as it will start hitting the
WARN_ON(!system_capabilities_finalized() in may_use_simd().

I doubt there are any current callers where that matters, but I've been
trying to avoid this sort of unnecessary pitfall in the CRC functions.

Checking the static key first eliminates this pitfall and is also more
efficient on CPUs that don't support the relevant CPU feature.

- Eric


  reply	other threads:[~2025-11-12 21:00 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-31 10:38 [PATCH v4 00/21] arm64: Move kernel mode FPSIMD buffer to the stack Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 01/21] crypto/arm64: aes-ce-ccm - Avoid pointless yield of the NEON unit Ard Biesheuvel
2025-11-06  7:08   ` Herbert Xu
2025-10-31 10:39 ` [PATCH v4 02/21] crypto/arm64: sm4-ce-ccm " Ard Biesheuvel
2025-11-06  7:11   ` Herbert Xu
2025-10-31 10:39 ` [PATCH v4 03/21] crypto/arm64: sm4-ce-gcm " Ard Biesheuvel
2025-11-06  7:15   ` Herbert Xu
2025-10-31 10:39 ` [PATCH v4 04/21] arm64/simd: Add scoped guard API for kernel mode SIMD Ard Biesheuvel
2025-10-31 13:55   ` Jonathan Cameron
2025-10-31 14:05     ` Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 05/21] ARM/simd: " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 06/21] crypto: aegis128-neon - Move to more abstract 'ksimd' guard API Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 07/21] raid6: " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 08/21] lib/crc: Switch ARM and arm64 to 'ksimd' scoped " Ard Biesheuvel
2025-10-31 13:49   ` Jonathan Cameron
2025-10-31 13:52     ` Ard Biesheuvel
2025-10-31 14:05       ` Ard Biesheuvel
2025-11-03 11:28         ` Jonathan Cameron
2025-11-04 15:32           ` Ard Biesheuvel
2025-11-12 20:58             ` Eric Biggers [this message]
2025-10-31 10:39 ` [PATCH v4 09/21] lib/crypto: " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 10/21] crypto/arm64: aes-ccm - Switch " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 11/21] crypto/arm64: aes-blk " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 12/21] crypto/arm64: aes-gcm " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 13/21] crypto/arm64: nhpoly1305 " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 14/21] crypto/arm64: polyval " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 15/21] crypto/arm64: sha3 " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 16/21] crypto/arm64: sm3 " Ard Biesheuvel
2025-10-31 13:52   ` Jonathan Cameron
2025-10-31 13:55     ` Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 17/21] crypto/arm64: sm4 " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 18/21] arm64/xorblocks: " Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 19/21] net/mlx5: Switch to more abstract scoped ksimd guard API on arm64 Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 20/21] arm64/fpu: Enforce task-context only for generic kernel mode FPU Ard Biesheuvel
2025-10-31 10:39 ` [PATCH v4 21/21] arm64/fpsimd: Allocate kernel mode FP/SIMD buffers on the stack Ard Biesheuvel
2025-10-31 14:16   ` Ard Biesheuvel
2025-11-11 17:12 ` [PATCH v4 00/21] arm64: Move kernel mode FPSIMD buffer to " Catalin Marinas

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=20251112205832.GC1760@sol \
    --to=ebiggers@kernel.org \
    --cc=ardb+git@google.com \
    --cc=ardb@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).