On Fri, Nov 15, 2024 at 03:47:24PM +0100, Harald Freudenberger wrote: > > Please note also that this implementation actively checks for > non-sleeping context before attempting to derive a protected > key from the given raw key material. This is due to the fact > that it may be (in the future) that this process has to interact > with crypto cards and thus requires IO traffic - which requires > sleeping allowed context. So there is a check for in_task() > and if this fails, -EOPNOTSUPP is returned to the caller. I don't think in_task is right. You cannot sleep when spinlocks are held and in general there is no way to test for that: /* * Are we running in atomic context? WARNING: this macro cannot * always detect atomic context; in particular, it cannot know about * held spinlocks in non-preemptible kernels. Thus it should not be * used in the general case to determine whether sleeping is possible. * Do not use in_atomic() in driver code. */ #define in_atomic() (preempt_count() != 0) While the Crypto API provides a mechanism for you to determine whether you can sleep (CRYPTO_TFM_REQ_MAY_SLEEP), I don't think it is acceptable to just randomly fail because you got called in a unsleepable context. The general solution for this problem is to make your algorithms asynchronous in the unsleepable context. See how we handle this in crypto/simd.c. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
