Messages in this thread | | | Date | Mon, 9 Sep 2019 19:00:52 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCH] mm: avoid slub allocation while holding list_lock |
| |
On Mon, Sep 09, 2019 at 12:10:16AM -0600, Yu Zhao wrote: > If we are already under list_lock, don't call kmalloc(). Otherwise we > will run into deadlock because kmalloc() also tries to grab the same > lock. > > Instead, allocate pages directly. Given currently page->objects has > 15 bits, we only need 1 page. We may waste some memory but we only do > so when slub debug is on. > > WARNING: possible recursive locking detected > -------------------------------------------- > mount-encrypted/4921 is trying to acquire lock: > (&(&n->list_lock)->rlock){-.-.}, at: ___slab_alloc+0x104/0x437 > > but task is already holding lock: > (&(&n->list_lock)->rlock){-.-.}, at: __kmem_cache_shutdown+0x81/0x3cb > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(&(&n->list_lock)->rlock); > lock(&(&n->list_lock)->rlock); > > *** DEADLOCK *** > > Signed-off-by: Yu Zhao <yuzhao@google.com>
Looks sane to me:
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
-- Kirill A. Shutemov
| |