From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: 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, will@kernel.org,
catalin.marinas@arm.com, Kees Cook <kees@kernel.org>
Subject: Re: [PATCH v3 0/2] arm64: Speed up CRC-32 using PMULL instructions
Date: Thu, 17 Oct 2024 15:04:09 -0700 [thread overview]
Message-ID: <20241017220409.GC11717@sol.localdomain> (raw)
In-Reply-To: <CAMj1kXFROGbn_49njp_rivEidqfgnLymOCRnfSkV_dTX_hAz9w@mail.gmail.com>
On Thu, Oct 17, 2024 at 06:30:19PM +0200, Ard Biesheuvel wrote:
> > Ard Biesheuvel (2):
> > arm64/lib: Handle CRC-32 alternative in C code
> > arm64/crc32: Implement 4-way interleave using PMULL
> >
>
> I'll need to respin this - the crc32_be code doesn't actually work correctly.
Right, good catch. It looks like it needs an rbit of the crc value at the
beginning and end. lib/crc32test.c doesn't actually test crc32_be_arm64_4way()
because it runs the tests with IRQs disabled; it probably shouldn't do that.
On a slightly related topic, since any crc32_le() and __crc32c_le() functions in
arch/*/lib/ are automatically exposed as shash algorithms via the crypto API
(this was already the case, but your other patch makes this more explicit by
properly separating them from the generic implementation), I wonder if all the
remaining arch/*/crypto/crc32*.c should be migrated to arch/*/lib/, and then
users of crc32 and crc32c like ext4 and f2fs should just use the library
functions instead of shash. That would simply things greatly. See e.g. the
horrible hacks used in ext4_chksum() and __f2fs_crc32()...
The only crc32 and crc32c implementations that *aren't* software based are those
in drivers/crypto/stm32/stm32-crc32.c and
drivers/crypto/inside-secure/safexcel_hash.c. Access to those would be lost by
going through lib. But I strongly suspect they exist just because the hardware
supported it and not because they are actually useful.
- Eric
next prev parent reply other threads:[~2024-10-17 22:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 9:41 [PATCH v3 0/2] arm64: Speed up CRC-32 using PMULL instructions Ard Biesheuvel
2024-10-17 9:41 ` [PATCH v3 1/2] arm64/lib: Handle CRC-32 alternative in C code Ard Biesheuvel
2024-10-17 9:41 ` [PATCH v3 2/2] arm64/crc32: Implement 4-way interleave using PMULL Ard Biesheuvel
2024-10-17 16:30 ` [PATCH v3 0/2] arm64: Speed up CRC-32 using PMULL instructions Ard Biesheuvel
2024-10-17 22:04 ` Eric Biggers [this message]
2024-10-17 22:40 ` Ard Biesheuvel
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=20241017220409.GC11717@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=herbert@gondor.apana.org.au \
--cc=kees@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=will@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