• Michael Wang's avatar
    slab: fix the DEADLOCK issue on l3 alien lock · 947ca185
    Michael Wang authored
    DEADLOCK will be report while running a kernel with NUMA and LOCKDEP enabled,
    the process of this fake report is:
    	   kmem_cache_free()	//free obj in cachep
    	-> cache_free_alien()	//acquire cachep's l3 alien lock
    	-> __drain_alien_cache()
    	-> free_block()
    	-> slab_destroy()
    	-> kmem_cache_free()	//free slab in cachep->slabp_cache
    	-> cache_free_alien()	//acquire cachep->slabp_cache's l3 alien lock
    Since the cachep and cachep->slabp_cache's l3 alien are in the same lock class,
    fake report generated.
    This should not happen since we already have init_lock_keys() which will
    reassign the lock class for both l3 list and l3 alien.
    However, init_lock_keys() was invoked at a wrong position which is before we
    invoke enable_cpucache() on each cache.
    Since until set slab_state to be FULL, we won't invoke enable_cpucache()
    on caches to build their l3 alien while creating them, so although we invoked
    init_lock_keys(), the l3 alien lock class won't change since we don't have
    them until invoked enable_cpucache() later.
    This patch will invoke init_lock_keys() after we done enable_cpucache()
    instead of before to avoid the fake DEADLOCK report.
    Michael traced the problem back to a commit in release 3.0.0:
    commit 30765b92
    Author: Peter Zijlstra <peterz@infradead.org>
    Date:   Thu Jul 28 23:22:56 2011 +0200
        slab, lockdep: Annotate the locks before using them
        Fernando found we hit the regular OFF_SLAB 'recursion' before we
        annotate the locks, cure this.
        The relevant portion of the stack-trace:
        > [    0.000000]  [<c085e24f>] rt_spin_lock+0x50/0x56
        > [    0.000000]  [<c04fb406>] __cache_free+0x43/0xc3
        > [    0.000000]  [<c04fb23f>] kmem_cache_free+0x6c/0xdc
        > [    0.000000]  [<c04fb2fe>] slab_destroy+0x4f/0x53
        > [    0.000000]  [<c04fb396>] free_block+0x94/0xc1
        > [    0.000000]  [<c04fc551>] do_tune_cpucache+0x10b/0x2bb
        > [    0.000000]  [<c04fc8dc>] enable_cpucache+0x7b/0xa7
        > [    0.000000]  [<c0bd9d3c>] kmem_cache_init_late+0x1f/0x61
        > [    0.000000]  [<c0bba687>] start_kernel+0x24c/0x363
        > [    0.000000]  [<c0bba0ba>] i386_start_kernel+0xa9/0xaf
    Reported-by: default avatarFernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
    Acked-by: default avatarPekka Enberg <penberg@kernel.org>
    Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
        Link: http://lkml.kernel.org/r/1311888176.2617.379.camel@laptop
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    The commit moved init_lock_keys() before we build up the alien, so we
    failed to reclass it.
    Cc: <stable@vger.kernel.org> # 3.0+
    Acked-by: default avatarChristoph Lameter <cl@linux.com>
    Tested-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: default avatarMichael Wang <wangyun@linux.vnet.ibm.com>
    Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>