On Sun, Apr 27, 2025 at 08:18:56AM +0800, Herbert Xu wrote: > On Sat, Apr 26, 2025 at 11:03:26AM -0700, Eric Biggers wrote: > > > > The SHA-256 library functions currently work in any context, and this patch > > series preserves that behavior. Changing that would be a separate change. > > I've already removed the SIMD fallback path and your patch is > adding it back.
While you've been pushing out a lot of random broken changes to shash recently, the SHA-256 library functions weren't SIMD-optimized until this patchset. > > But also as I've explained before, for the library API the performance > > benefit > > of removing the crypto_simd_usable() doesn't seem to be worth the footgun > > that > > would be introduced. Your position is, effectively, that if someone calls > > one > > of the sha256*() functions from a hardirq, we should sometimes corrupt a > > random > > task's FPU registers. That's a really bad bug that is very difficult to > > root-cause. My position is that we should make it just work as expected. > > kernel_fpu_begin already does a WARN_ON when called in hardirq > context and it can't safely use the FPU, there is no silent > corruption. Only when CONFIG_X86_DEBUG_FPU is enabled, which people don't enable in production. And even if that is enabled, it's just a WARN, so the registers still get used and corrupted anyway. - Eric
