Am Dienstag, 21. August 2018, 14:48:11 CEST schrieb Ondrej Mosnáček: Hi Ondrej, Marcelo, (+Marcelo) > Looking at crypto/algif_skcipher.c, I can see that skcipher_recvmsg() > holds the socket lock the whole time and yet passes > CRYPTO_TFM_REQ_MAY_SLEEP to the cipher implementation. Isn't that > wrong? I think you are referring to lock_sock(sk)? If so, this should not be the culprit: the socket lock is in essence a mutex- like operation with its own wait queue that it allowed to sleep. In lock_sock_nested that is called by lock_sock it even has the call of might_sleep which indicates that the caller may be put to sleep. Looking into the code (without too much debugging) I see in the function p8_aes_cbc_encrypt that is part of the stack trace the call to preempt_disable() which starts an atomic context. The preempt_enable() is invoked after the walk operation. The preempt_disable increases the preempt_count. That counter is used by in_atomic() to check whether we are in atomic context. The issue is that blkcipher_walk_done may call crypto_yield() which then invokes cond_resched if the implementation is allowed to sleep. @Marcelo: shouldn't be the sleep flag be cleared when entering the preempt_disable section? Ciao Stephan
