[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YwhPtnL6yVG0K2Lo@sol.localdomain>
Date: Thu, 25 Aug 2022 21:44:38 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>,
"Jason A . Donenfeld " <Jason@...c4.com>,
"Justin M. Forbes" <jforbes@...oraproject.org>
Cc: linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: [PATCH v3 2/3] crypto: lib - move __crypto_xor into utils
Herbert, Jason, and Justin:
On Mon, Jul 25, 2022 at 11:36:35AM -0700, Eric Biggers wrote:
> diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
> index b09d9d6546cbc3..7e9683e9f5c636 100644
> --- a/lib/crypto/Kconfig
> +++ b/lib/crypto/Kconfig
> @@ -36,7 +36,7 @@ config CRYPTO_ARCH_HAVE_LIB_CHACHA
>
> config CRYPTO_LIB_CHACHA_GENERIC
> tristate
> - select XOR_BLOCKS
> + select CRYPTO_LIB_UTILS
> help
> This symbol can be depended upon by arch implementations of the
> ChaCha library interface that require the generic code as a
Just a heads up; the unnecessary selection of XOR_BLOCKS here (which got
backported to v5.10.120 and v5.15.45 by "lib/crypto: add prompts back to crypto
libraries") can be considered an actual bug, as it increases boot time on
systems that didn't have it selected before. This is because the code enabled
by XOR_BLOCKS (crypto/xor.c) runs a benchmark, which takes some time. It
doesn't take *that* long, but it got noticed as a regression nonetheless, and it
needs to be fixed. My patch series happens to have fixed this, but I didn't
have it mind that it was a real bug fix.
Herbert, any chance that you could send my patch series to Linus without waiting
for the next merge window, so that it can be backported?
- Eric
Powered by blists - more mailing lists