[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8DDmBg6J31pS0KW@gondor.apana.org.au>
Date: Fri, 13 Jan 2023 10:36:08 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Robert Elliott <elliott@....com>, davem@...emloft.net,
Jason@...c4.com, ardb@...nel.org, ap420073@...il.com,
David.Laight@...lab.com, tim.c.chen@...ux.intel.com,
peter@...jl.ca, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, linux-crypto@...r.kernel.org,
x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/13] crypto: x86/sha - yield FPU context during long
loops
On Thu, Jan 12, 2023 at 10:46:42AM -0800, Eric Biggers wrote:
>
> Right, this used to exist, but it didn't actually do anything, and it had
> suffered heavily from bitrot. For example, some callers specified MAY_SLEEP
> when actually they couldn't sleep. IIRC, some callers also didn't even bother
> initializing the flags, so they were passing uninitialized memory. So I removed
> it in commit 877b5691f27a ("crypto: shash - remove shash_desc::flags").
>
> Has there been any consideration of just adding the crypto_shash_update_large()
> helper function that I had mentioned in the commit message of 877b5691f27a?
I had forgotten about this :)
Perhaps we should just convert any users that trigger these warnings
over to ahash? The shash interface was never meant to process large
amounts of data anyway.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists