possible slab deadlock while doing ifenslave

possible slab deadlock while doing ifenslave

[Hans Schillstrom]

Hello,
I got this when I was testing a VLAN patch i.e. using Dave Millers net-next from today.
When doing this on a single core i686 I got the warning every time,
however ifenslave is not hanging it's just a warning
Have not been testing this on a multicore jet.

There is no warnings with a 3.0.4 kernel.

Is this a known warning ?

~ # ifenslave bond0 eth1 eth2

=============================================
[ INFO: possible recursive locking detected ]
3.1.0-rc9+ #3
---------------------------------------------
ifenslave/749 is trying to acquire lock:
 (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb

but task is already holding lock:
 (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&parent->list_lock)->rlock);
  lock(&(&parent->list_lock)->rlock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by ifenslave/749:
 #0:  (rtnl_mutex){+.+.+.}, at: [<c1321884>] rtnl_lock+0x14/0x20
 #1:  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb

stack backtrace:
Pid: 749, comm: ifenslave Not tainted 3.1.0-rc9+ #3
Call Trace:
 [<c1421e14>] ? printk+0x2d/0x2f
 [<c1076a01>] __lock_acquire+0xdc1/0x18d0
 [<c1077ae2>] lock_acquire+0x82/0x1b0
 [<c14234a0>] ? cache_flusharray+0x41/0xdb
 [<c14291ec>] ? _raw_spin_unlock+0x2c/0x50
 [<c14289e2>] _raw_spin_lock+0x42/0x50
 [<c14234a0>] ? cache_flusharray+0x41/0xdb
 [<c14234a0>] cache_flusharray+0x41/0xdb
 [<c10fc378>] kmem_cache_free+0xa8/0x190
 [<c10fc56b>] slab_destroy+0x10b/0x140
 [<c10fc727>] free_block+0x187/0x1d0
 [<c14234e7>] cache_flusharray+0x88/0xdb
 [<c10fcc5e>] kfree+0x10e/0x220
 [<f815543d>] ? rtl8169_rx_clear+0x6d/0xa0 [r8169]
 [<c10fcc36>] ? kfree+0xe6/0x220
 [<f815543d>] ? rtl8169_rx_clear+0x6d/0xa0 [r8169]
 [<f815543d>] rtl8169_rx_clear+0x6d/0xa0 [r8169]
 [<f81563a0>] rtl8169_close+0x110/0x230 [r8169]
 [<c1311bd9>] __dev_close_many+0x69/0xb0
 [<c1045737>] ? local_bh_enable_ip+0x67/0xd0
 [<c1311c44>] __dev_close+0x24/0x40
 [<c13159a2>] __dev_change_flags+0x82/0x150
 [<c1321884>] ? rtnl_lock+0x14/0x20
 [<c1315b11>] dev_change_flags+0x21/0x60
 [<c1394140>] devinet_ioctl+0x5a0/0x710
 [<c13950cd>] inet_ioctl+0x8d/0xb0
 [<c12fd69f>] sock_ioctl+0x5f/0x270
 [<c12fd640>] ? sock_fasync+0xd0/0xd0
 [<c11180a6>] do_vfs_ioctl+0x86/0x5a0
 [<c106575b>] ? up_read+0x1b/0x30
 [<c102532b>] ? do_page_fault+0x18b/0x3c0
 [<c1108a67>] ? fget_light+0x167/0x2f0
 [<c130046c>] ? sys_socketcall+0x5c/0x2a0
 [<c11185f2>] sys_ioctl+0x32/0x60
 [<c1429f50>] sysenter_do_call+0x12/0x36


-- 
Regards
Hans Schillstrom <hans@schillstrom.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: possible slab deadlock while doing ifenslave

[David Rientjes]

On Wed, 12 Oct 2011, Hans Schillstrom wrote:

> Hello,
> I got this when I was testing a VLAN patch i.e. using Dave Millers net-next from today.
> When doing this on a single core i686 I got the warning every time,
> however ifenslave is not hanging it's just a warning
> Have not been testing this on a multicore jet.
> 
> There is no warnings with a 3.0.4 kernel.
> 
> Is this a known warning ?
> 
> ~ # ifenslave bond0 eth1 eth2
> 
> =============================================
> [ INFO: possible recursive locking detected ]
> 3.1.0-rc9+ #3
> ---------------------------------------------
> ifenslave/749 is trying to acquire lock:
>  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb
> 
> but task is already holding lock:
>  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb
> 

Hmm, the only candidate that I can see that may have caused this is 
83835b3d9aec ("slab, lockdep: Annotate slab -> rcu -> debug_object -> 
slab").  Could you try reverting that patch in your local tree and seeing 
if it helps?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: possible slab deadlock while doing ifenslave

[Hans Schillstrom]

On Wednesday, October 12, 2011 22:35:51 David Rientjes wrote:
> On Wed, 12 Oct 2011, Hans Schillstrom wrote:
> 
> > Hello,
> > I got this when I was testing a VLAN patch i.e. using Dave Millers net-next from today.
> > When doing this on a single core i686 I got the warning every time,
> > however ifenslave is not hanging it's just a warning
> > Have not been testing this on a multicore jet.
> > 
> > There is no warnings with a 3.0.4 kernel.
> > 
> > Is this a known warning ?
> > 
> > ~ # ifenslave bond0 eth1 eth2
> > 
> > =============================================
> > [ INFO: possible recursive locking detected ]
> > 3.1.0-rc9+ #3
> > ---------------------------------------------
> > ifenslave/749 is trying to acquire lock:
> >  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb
> > 
> > but task is already holding lock:
> >  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb
> > 
> 
> Hmm, the only candidate that I can see that may have caused this is 
> 83835b3d9aec ("slab, lockdep: Annotate slab -> rcu -> debug_object -> 
> slab").  Could you try reverting that patch in your local tree and seeing 
> if it helps?
> 

That was not our candidate ...
i.e. same results

Thanks
Hans

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: possible slab deadlock while doing ifenslave

[David Rientjes]

On Thu, 13 Oct 2011, Hans Schillstrom wrote:

> > > Hello,
> > > I got this when I was testing a VLAN patch i.e. using Dave Millers net-next from today.
> > > When doing this on a single core i686 I got the warning every time,
> > > however ifenslave is not hanging it's just a warning
> > > Have not been testing this on a multicore jet.
> > > 
> > > There is no warnings with a 3.0.4 kernel.
> > > 
> > > Is this a known warning ?
> > > 
> > > ~ # ifenslave bond0 eth1 eth2
> > > 
> > > =============================================
> > > [ INFO: possible recursive locking detected ]
> > > 3.1.0-rc9+ #3
> > > ---------------------------------------------
> > > ifenslave/749 is trying to acquire lock:
> > >  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb
> > > 
> > > but task is already holding lock:
> > >  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb
> > > 
> > 
> > Hmm, the only candidate that I can see that may have caused this is 
> > 83835b3d9aec ("slab, lockdep: Annotate slab -> rcu -> debug_object -> 
> > slab").  Could you try reverting that patch in your local tree and seeing 
> > if it helps?
> > 
> 
> That was not our candidate ...
> i.e. same results
> 

Ok, I think this may be related to what Sitsofe reported in the "lockdep 
recursive locking detected" thread on LKML (see 
http://marc.info/?l=linux-kernel&m=131805699106560).

Peter and Christoph hypothesized that 056c62418cc6 ("slab: fix lockdep 
warnings") may not have had full coverage when setting lockdep classes for 
kmem_list3 locks that may be called inside of each other because of 
off-slab metadata.

I think it's safe to say there is no deadlock possibility here or we would 
have seen it since 2006 and this is just a matter of lockdep annotation 
that needs to be done.  So don't worry too much about the warning even 
though I know it's annoying and it suppresses future lockdep output (even 
more annoying!).

I'm not sure if there's a patch to address that yet, I think one was in 
the works.  If not, I'll take a look at rewriting that lockdep annotation.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: possible slab deadlock while doing ifenslave

[Peter Zijlstra]

On Thu, 2011-10-13 at 16:03 -0700, David Rientjes wrote:

> Ok, I think this may be related to what Sitsofe reported in the "lockdep 
> recursive locking detected" thread on LKML (see 
> http://marc.info/?l=linux-kernel&m=131805699106560).
> 
> Peter and Christoph hypothesized that 056c62418cc6 ("slab: fix lockdep 
> warnings") may not have had full coverage when setting lockdep classes for 
> kmem_list3 locks that may be called inside of each other because of 
> off-slab metadata.
> 
> I think it's safe to say there is no deadlock possibility here or we would 
> have seen it since 2006 and this is just a matter of lockdep annotation 
> that needs to be done.  So don't worry too much about the warning even 
> though I know it's annoying and it suppresses future lockdep output (even 
> more annoying!).
> 
> I'm not sure if there's a patch to address that yet, I think one was in 
> the works.  If not, I'll take a look at rewriting that lockdep annotation.

Urgh, I so totally forgot about that.. :-/ So no, no patch yet.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: possible slab deadlock while doing ifenslave

[Hans Schillstrom]

On Friday, October 14, 2011 01:03:40 David Rientjes wrote:
> On Thu, 13 Oct 2011, Hans Schillstrom wrote:
> 
> > > > Hello,
> > > > I got this when I was testing a VLAN patch i.e. using Dave Millers net-next from today.
> > > > When doing this on a single core i686 I got the warning every time,
> > > > however ifenslave is not hanging it's just a warning
> > > > Have not been testing this on a multicore jet.
> > > > 
> > > > There is no warnings with a 3.0.4 kernel.
> > > > 
> > > > Is this a known warning ?
> > > > 
> > > > ~ # ifenslave bond0 eth1 eth2
> > > > 
> > > > =============================================
> > > > [ INFO: possible recursive locking detected ]
> > > > 3.1.0-rc9+ #3
> > > > ---------------------------------------------
> > > > ifenslave/749 is trying to acquire lock:
> > > >  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb
> > > > 
> > > > but task is already holding lock:
> > > >  (&(&parent->list_lock)->rlock){-.-...}, at: [<c14234a0>] cache_flusharray+0x41/0xdb
> > > > 
> > > 
> > > Hmm, the only candidate that I can see that may have caused this is 
> > > 83835b3d9aec ("slab, lockdep: Annotate slab -> rcu -> debug_object -> 
> > > slab").  Could you try reverting that patch in your local tree and seeing 
> > > if it helps?
> > > 
> > 
> > That was not our candidate ...
> > i.e. same results
> > 
> 
> Ok, I think this may be related to what Sitsofe reported in the "lockdep 
> recursive locking detected" thread on LKML (see 
> http://marc.info/?l=linux-kernel&m=131805699106560).
> 
> Peter and Christoph hypothesized that 056c62418cc6 ("slab: fix lockdep 
> warnings") may not have had full coverage when setting lockdep classes for 
> kmem_list3 locks that may be called inside of each other because of 
> off-slab metadata.
> 
> I think it's safe to say there is no deadlock possibility here or we would 
> have seen it since 2006 and this is just a matter of lockdep annotation 
> that needs to be done.  So don't worry too much about the warning even 
> though I know it's annoying and it suppresses future lockdep output (even 
> more annoying!).

I have not seen any deadlock, and so far I've got hundreds of this warnings.

> 
> I'm not sure if there's a patch to address that yet, I think one was in 
> the works.  If not, I'll take a look at rewriting that lockdep annotation.
> 

If you want me to do some more testing, I keep the setup for a couple of month.

Thanks
Hans

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: possible slab deadlock while doing ifenslave

[Peter Zijlstra]

On Fri, 2011-10-14 at 01:21 +0200, Peter Zijlstra wrote:
> On Thu, 2011-10-13 at 16:03 -0700, David Rientjes wrote:
> 
> > Ok, I think this may be related to what Sitsofe reported in the "lockdep 
> > recursive locking detected" thread on LKML (see 
> > http://marc.info/?l=linux-kernel&m=131805699106560).
> > 
> > Peter and Christoph hypothesized that 056c62418cc6 ("slab: fix lockdep 
> > warnings") may not have had full coverage when setting lockdep classes for 
> > kmem_list3 locks that may be called inside of each other because of 
> > off-slab metadata.
> > 
> > I think it's safe to say there is no deadlock possibility here or we would 
> > have seen it since 2006 and this is just a matter of lockdep annotation 
> > that needs to be done.  So don't worry too much about the warning even 
> > though I know it's annoying and it suppresses future lockdep output (even 
> > more annoying!).
> > 
> > I'm not sure if there's a patch to address that yet, I think one was in 
> > the works.  If not, I'll take a look at rewriting that lockdep annotation.
> 
> Urgh, I so totally forgot about that.. :-/ So no, no patch yet.

---
Subject: slab, lockdep: Fix silly bug
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Mon Nov 28 21:12:40 CET 2011

Commit 30765b92 ("slab, lockdep: Annotate the locks before using
them") moves the init_lock_keys() call from after g_cpucache_up =
FULL, to before it. And overlooks the fact that init_node_lock_keys()
tests for it and ignores everything !FULL.

Introduce a LATE stage and change the lockdep test to be <LATE.

Cc: stable@kernel.org
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-gadqbdfxorhia1w5ewmoiodd@git.kernel.org
---
Index: linux-2.6/mm/slab.c
===================================================================
--- linux-2.6.orig/mm/slab.c
+++ linux-2.6/mm/slab.c
@@ -595,6 +595,7 @@ static enum {
 	PARTIAL_AC,
 	PARTIAL_L3,
 	EARLY,
+	LATE,
 	FULL
 } g_cpucache_up;
 
@@ -671,7 +672,7 @@ static void init_node_lock_keys(int q)
 {
 	struct cache_sizes *s = malloc_sizes;
 
-	if (g_cpucache_up != FULL)
+	if (g_cpucache_up < LATE)
 		return;
 
 	for (s = malloc_sizes; s->cs_size != ULONG_MAX; s++) {
@@ -1666,6 +1667,8 @@ void __init kmem_cache_init_late(void)
 {
 	struct kmem_cache *cachep;
 
+	g_cpucache_up = LATE;
+
 	/* Annotate slab for lockdep -- annotate the malloc caches */
 	init_lock_keys();
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: possible slab deadlock while doing ifenslave

[Peter Zijlstra]

On Mon, 2011-11-28 at 22:19 +0100, Peter Zijlstra wrote:

> > Urgh, I so totally forgot about that.. :-/ So no, no patch yet.

On top of the previous patch I've got this, which is probably less
critical but makes it all more comprehensive or so..

---
Subject: slab, lockdep: Annotate all slab caches
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Mon Nov 28 19:51:51 CET 2011

Currently we only annotate the kmalloc caches, annotate all of them.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-10bey2cgpcvtbdkgigaoab8w@git.kernel.org
---
 mm/slab.c |   52 ++++++++++++++++++++++++++++------------------------
 1 file changed, 28 insertions(+), 24 deletions(-)
Index: linux-2.6/mm/slab.c
===================================================================
--- linux-2.6.orig/mm/slab.c
+++ linux-2.6/mm/slab.c
@@ -607,6 +607,12 @@ int slab_is_available(void)
 	return g_cpucache_up >= EARLY;
 }
 
+/*
+ * Guard access to the cache-chain.
+ */
+static DEFINE_MUTEX(cache_chain_mutex);
+static struct list_head cache_chain;
+
 #ifdef CONFIG_LOCKDEP
 
 /*
@@ -668,38 +674,41 @@ static void slab_set_debugobj_lock_class
 		slab_set_debugobj_lock_classes_node(cachep, node);
 }
 
-static void init_node_lock_keys(int q)
+static void init_lock_keys(struct kmem_cache *cachep, int node)
 {
-	struct cache_sizes *s = malloc_sizes;
+	struct kmem_list3 *l3;
 
 	if (g_cpucache_up < LATE)
 		return;
 
-	for (s = malloc_sizes; s->cs_size != ULONG_MAX; s++) {
-		struct kmem_list3 *l3;
+	l3 = cachep->nodelists[node];
+	if (!l3 || OFF_SLAB(cachep))
+		return;
 
-		l3 = s->cs_cachep->nodelists[q];
-		if (!l3 || OFF_SLAB(s->cs_cachep))
-			continue;
+	slab_set_lock_classes(cachep, &on_slab_l3_key, &on_slab_alc_key, node);
+}
 
-		slab_set_lock_classes(s->cs_cachep, &on_slab_l3_key,
-				&on_slab_alc_key, q);
-	}
+static void init_node_lock_keys(int node)
+{
+	struct kmem_cache *cachep;
+
+	list_for_each_entry(cachep, &cache_chain, next)
+		init_lock_keys(cachep, node);
 }
 
-static inline void init_lock_keys(void)
+static inline void init_cachep_lock_keys(struct kmem_cache *cachep)
 {
 	int node;
 
 	for_each_node(node)
-		init_node_lock_keys(node);
+		init_lock_keys(cachep, node);
 }
 #else
-static void init_node_lock_keys(int q)
+static void init_node_lock_keys(int node)
 {
 }
 
-static inline void init_lock_keys(void)
+static void init_cachep_lock_keys(struct kmem_cache *cachep)
 {
 }
 
@@ -712,12 +721,6 @@ static void slab_set_debugobj_lock_class
 }
 #endif
 
-/*
- * Guard access to the cache-chain.
- */
-static DEFINE_MUTEX(cache_chain_mutex);
-static struct list_head cache_chain;
-
 static DEFINE_PER_CPU(struct delayed_work, slab_reap_work);
 
 static inline struct array_cache *cpu_cache_get(struct kmem_cache *cachep)
@@ -1669,14 +1672,13 @@ void __init kmem_cache_init_late(void)
 
 	g_cpucache_up = LATE;
 
-	/* Annotate slab for lockdep -- annotate the malloc caches */
-	init_lock_keys();
-
 	/* 6) resize the head arrays to their final sizes */
 	mutex_lock(&cache_chain_mutex);
-	list_for_each_entry(cachep, &cache_chain, next)
+	list_for_each_entry(cachep, &cache_chain, next) {
+		init_cachep_lock_keys(cachep);
 		if (enable_cpucache(cachep, GFP_NOWAIT))
 			BUG();
+	}
 	mutex_unlock(&cache_chain_mutex);
 
 	/* Done! */
@@ -2479,6 +2481,8 @@ kmem_cache_create (const char *name, siz
 		slab_set_debugobj_lock_classes(cachep);
 	}
 
+	init_cachep_lock_keys(cachep);
+
 	/* cache setup completed, link it into the list */
 	list_add(&cachep->next, &cache_chain);
 oops:

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: possible slab deadlock while doing ifenslave

[Christoph Lameter]

On Mon, 28 Nov 2011, Peter Zijlstra wrote:

> Currently we only annotate the kmalloc caches, annotate all of them.

What is the benefit? The metadata for off slab caches uses the
kmalloc array. Should the annotation for the kmalloc cache not be
sufficient by putting that into a different lock category? Non-kmalloc
caches already have a different lock category before this patch right?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: possible slab deadlock while doing ifenslave

[Peter Zijlstra]

On Tue, 2011-11-29 at 08:58 -0600, Christoph Lameter wrote:
> On Mon, 28 Nov 2011, Peter Zijlstra wrote:
> 
> > Currently we only annotate the kmalloc caches, annotate all of them.
> 
> What is the benefit? 

Extra paranoia I guess..  I was fairly sure it was pointless, but I send
it anyway.

> The metadata for off slab caches uses the
> kmalloc array. Should the annotation for the kmalloc cache not be
> sufficient by putting that into a different lock category? Non-kmalloc
> caches already have a different lock category before this patch right?

Yeah, we annotate all kmalloc caches that have l3 and aren't OFF_SLAB().


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: possible slab deadlock while doing ifenslave

[Christoph Lameter]

On Mon, 28 Nov 2011, Peter Zijlstra wrote:

> Commit 30765b92 ("slab, lockdep: Annotate the locks before using
> them") moves the init_lock_keys() call from after g_cpucache_up =
> FULL, to before it. And overlooks the fact that init_node_lock_keys()
> tests for it and ignores everything !FULL.
>
> Introduce a LATE stage and change the lockdep test to be <LATE.

Acked-by: Christoph Lameter <cl@linux.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>