On Wed, Sep 23, 2026 at 03:47:41PM +1000, Herbert Xu wrote: > Why did you set the NO_FALLBACK flag? This is only meant to be used > by very specific cases such as s390.
Being async, these algs get NEED_FALLBACK forced by ahash_prepare_alg() unless NO_FALLBACK is set, so crypto_ahash_init_tfm() tries to allocate a same-name synchronous REQ_VIRT provider -- which doesn't work here: - shake128/256, cshake, kmac and poly1305 have no matching provider registered in this tree, so the allocation fails and the transform can't be created at all. NO_FALLBACK is required to instantiate them. - sha2, sha3 and sm3 do have a software provider, so the transform loads, but the auto-fallback can't stand in for the hardware on the streaming path: our exported state is the opaque HW save/restore checkpoint, not the canonical state, so a multi-part export/import round-trip through the fallback misinterprets it (and for SHA-2/SHA-3 the statesize exceeds HASH_MAX_STATESIZE, so ahash_do_req_chain() returns -ENOSYS). A one-shot digest could still use the software provider, but a fallback that only covers one-shot and corrupts streaming isn't usable. Same flag as s390, same underlying reason -- no generic transform can stand in for the hardware -- though the obstruction differs: protected keys there, opaque (and for SHA-2/SHA-3 oversized) HW state here. Thanks, Alex
