On Wed, Apr 02, 2025 at 10:19:30AM -0700, Eric Biggers wrote: > > This seems premature. crypto_shash is documented to be usable in any context. > See the "Context:" comments in include/crypto/hash.h. Similarly, developers > expect lib/ functions to be available in any context unless otherwise > documented. Doing slow computations in a hard IRQ is a bad idea. The whole point of a hard IRQ handler is to set a flag and defer everything to a different context. Please show me one good reason why we should allow crypto in a hard IRQ. > IMO, doing it for lib/ too would be going too far though. The lib/ functions > should be easy to use and not have random requirements on the calling context. > And since they're just functions, it's easy for them to fall back to the generic > functions when needed. Also note that for very short inputs it can actually be > faster to use no-SIMD code, as that avoids the overhead of a kernel-mode SIMD > section. So the fallback sometimes exists anyway for that. We already disallow SIMD in hard IRQs anyway (may_use_simd is always false in that context). The only thing you could use is the generic implementation. So making this change in lib/crypto does not take any functionality away. You could still invoke the generic lib/crypto code directly. It does mean that we take away a completely useless check for people who are actually doing crypto because crypto work should never be done in a hard IRQ. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
