Sebastian Siewior <linux-crypto@xxxxxxxxxxxxxxxx> wrote: >>And, btw, do not use mutex in encryption path, it is not supposed to >>sleep in ipsec. > I am aware of that but again: I might be totally wrong. Herbert > introduced a async API. My understanding was that he wants to queue > encrypt+decrypt (not setkey) and process it later in a dedicated thread. > On the other hand: what is async when still evrything happny sync. > He's tcrypt code queues a request, and calls Evgeniy is absolutely right here. While it is true that the whole point of async is so that you can go away and do something else while the crypto operation is in place, it does not mean that the crypto driver itself can sleep when handling a request. For example, the caller might be IPsec which runs in an unsleepable BH context. It wants to queue the packet for processing and have the crypto layer call it back when it's done. There is no explicit sleeping involved here. So if you need locking you should use something like a spin lock. > wait_for_completion_interruptible() so he does sleep and waits until the > cipher finishes (in a seperate kthread). However this is only the case > if crypto_ablkcipher_XXX() returns with -EINPROGRESS or -EBUSY. In case Of course the caller can sleep if it is safe. tcrypt always runs in process context which is why it can afford to sleep here. IPsec on the other hand would not be able to do that. >>HIFN supports at least 12 different ciphers/mode (3des, des and aes, >>each one with 4 modes), so it is not a good idea to put them all into >>separated structures, so I rised a question about it. > This might be cool. I'm all for helpers to reduce typing here :) However, we really do need separate objects for each block cipher since from the crypto API's point of view they're totally unrelated. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
