On Mon, Oct 05, 2026 at 05:04:25PM +0000, Ousherovitch, Alex wrote: > For the algorithms that have a generic provider -- SHA-2, > SHA-3, SM3, HMAC(SHA-2/SHA-3), CMAC(AES), CMAC(SM4) and XCBC(SM4) -- > v6 switches to the fallback/digest-only model: > > - drop the NO_FALLBACK / BLOCK_ONLY / REQ_VIRT flags [...] > > That also answers your NO_FALLBACK question: the flag is gone.
One correction to the above before I post v6, so it doesn't look like a quiet regression in the patches: that holds for SHA-2, SHA-3, SM3 and HMAC, but not for CMAC(AES), CMAC(SM4) and XCBC(SM4) -- those three keep NO_FALLBACK and REQ_VIRT. The reason is the generic fallback itself. crypto/cmac.c and crypto/xcbc.c implement only descsize, with no export_core/import_core, so the core marks them NO_EXPORT_CORE and crypto_ahash_init_tfm() cannot wrap them as crypto_ahash_fb() -- that allocation carries the bit in its mask and fails. For an async digest-only MAC that leaves no choice: ahash_prepare_alg() forces NEED_FALLBACK unless NO_FALLBACK is set, and the fallback it would otherwise build is unallocatable here. So these three set NO_FALLBACK, keep REQ_VIRT, and allocate the same generic cmac/xcbc transform themselves to service the non-digest paths. Behaviorally they match the hashes -- hardware .digest() only, with .init/.update/.final/.export/.import forwarded to the generic transform (crypto_ahash_fb() where the core provides it, a driver-allocated one for these three) and the virtual-address path in software; only the flag differs. HMAC does not hit this because crypto/hmac.c provides export_core/import_core. BLOCK_ONLY is gone everywhere, as described, and the rest of that message stands. If you'd rather these three didn't carry the flag, I can drop cmac(aes), cmac(sm4) and xcbc(sm4) from the driver instead. Thanks, Alex
