On Thu, Jan 16, 2025 at 05:12:57PM +0800, Herbert Xu wrote: > On Thu, Jan 16, 2025 at 10:00:36AM +0100, Harald Freudenberger wrote: > > > > Eric your idea was whirling around in my head for at least 3 month now. > > It would be great to have a way to offer an shash() implementation which > > clearly states that it is not for use in atomic context. E.g. like as you > > wrote with a new flag. I'll work out something in this direction and push > > it onto the crypto mailing list :-) > > I don't like this flag because we'd have to modify every other > hash user. But in practice it's the opposite. Making it an ahash forces users who would otherwise just be using shash to use ahash instead. > For example, this would result in your algorithm > being unavailable to IPsec despite it being an ahash user (because > it can't sleep). No one is asking for it to be available to IPsec. And this is just a MAC, not a cipher. But more generally, sleepable algorithms could still be used via an adapter using cryptd, or by making IPsec support using a workqueue like all the storage encryption/integrity systems already do. In any case this would be a rare (or nonexistent?) use case and should be treated as such. > I think the dm-crypt patch should wait until after I have added > virtual address support to ahash. Then we could compare it properly > with shash. That won't solve all the problems with ahash, for example the per-request allocation. We'll still end up with something that is worse for 99% of users, while also doing a very poor job supporting the 1% (even assuming it's 1% and not 0% which it very well might be) who actually think they want off-CPU hardware crypto acceleration. Not to mention the nonsense like having "synchronous asynchronous hashes". I think it's time to admit that the approach you're trying to take with the crypto API is wrong. This has been known for years. The primary API needs to be designed around and optimized for software crypto, which is what nearly everyone wants. - Eric
