Patch Upstream: slab: fix the DEADLOCK issue on l3 alien lock

commit: 947ca1856a7e60aa6d20536785e6a42dff25aa6e
From: Michael Wang <[email protected]>
Date: Wed, 5 Sep 2012 10:33:18 +0800
Subject: slab: fix the DEADLOCK issue on l3 alien lock

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 30765b92ada267c5395fc788623cb15233276f5c

Author: Peter Zijlstra <[email protected]>
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: Fernando Lopez-Lezcano <[email protected]>
    Acked-by: Pekka Enberg <[email protected]>
    Signed-off-by: Peter Zijlstra <[email protected]>
    Link: http://lkml.kernel.org/r/1311888176.2617.379.camel@laptop
    Signed-off-by: Ingo Molnar <[email protected]>

The commit moved init_lock_keys() before we build up the alien, so we failed to reclass it.

Cc <[email protected]> # 3.0+

Acked-by Christoph Lameter <[email protected]>

Tested-by Paul E. McKenney <[email protected]>

Signed-off-by Michael Wang <[email protected]>

Signed-off-by Pekka Enberg <[email protected]>