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
|