On 1/2/23 19:47, Eric Biggers wrote:
On Mon, Jan 02, 2023 at 07:33:15PM -0500, Sweet Tea Dorminy wrote:Anyway, crypto_alloc_skcipher() takes a lock (crypto_alg_sem) under which memory is allocated with GFP_KERNEL. So neither preloading kernel modules nor memalloc_nofs_save() helps for it; it's still not GFP_NOFS-safe.I'm still confused. My understanding is that memalloc_nofs_save() means all allocations on that thread until memalloc_nofs_restore() is called effectively gets GFP_NOFS appended to the allocation flags. So since crypto_alloc_skcipher()'s allocation appears to be on the same thread as we'd be calling memalloc_nofs_save/restore(), it would presumably get allocated as though it had flags GFP_KERNEL | GFP_NOFS, even though the call is kzalloc(..., GFP_KERNEL, ...). I don't understand how the lock would make a difference. Can you elaborate? Sorry for my confusion...Other tasks (using the crypto API for another purpose, perhaps totally unrelated to fs/crypto/) can take crypto_alg_sem without taking the same precaution. So, when your task that is running in fs-reclaim context and has used memalloc_nofs_save() tries to take the same lock, it might be that the lock is already held by another thread that is waiting for fs-reclaim to complete in order to satisfy a GFP_KERNEL allocation. That's a deadlock. Locks are only GFP_NOFS-safe when everyone agrees to use them that way. - Eric
Ah that is definitely what I was missing, I've never had to think about that interaction. Thank you for explaining!
|