On Thu, Dec 14, 2000 at 12:04:26PM +0100, Olaf Titz wrote: > As stated in <linux/crypto.h> the encrypt and decrypt functions of the > cipher implementations may sleep. This is very unfortunate, as there > is no way to use them in atomic context (e.g. network driver output > routine, required for CIPE etc.) > > What is the actual state on this: > - Are there implementations which really do sleep? I can't think of a > reason why they _have_ to. Currently only to reduce latency. Loopback crypto latency doesn't look good on tests. Also, I documented that these functions could sleep to get users who can't have their crypto functions sleep out of the wood :-). The sleeping interface can be hooked up to harware accelleration, while a non-sleeping version will have to be implemented in software. > - Is there a way to find out whether an implementation does this? It is done in crypto/gen_cbc.h for instance. It checks current->need_reshed and reshedules if needed. > - How can it be fixed? Usually this would require a GFP_* argument to > each function which may allocate memory. In the current implementation, getting a version that doesn't sleep simply requires disabling the if (current->need_reshed) test. This can be implemented by having a flag in cipher_context telling the cipher implementation to avoid sleeping. However, in the future this means we always have to have a software-version of any hardware-accellerated cipher, or _only_ provide hardware-accelleration using a work-queue interface where we invoke a callback when the job is done. astor -- Alexander Kjeldaas Mail: astor@xxxxxxx finger astor@xxxxxxxxxxxxxxxxx for OpenPGP key. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
