Peter,
There was a little conflict with my merge of 3.4.14 due to the backport
of this patch:
commit 947ca1856a7e60aa6d20536785e6a42dff25aa6e
Author: Michael Wang <[email protected]>
Date: Wed Sep 5 10:33:18 2012 +0800
slab: fix the DEADLOCK issue on l3 alien lock
Could you just confirm that my fix is correct.
Thanks,
-- Steve
>From 741c5d3c42ad58b577d0ee602dd1f0bb52b7b92b Mon Sep 17 00:00:00 2001
From: Steven Rostedt <[email protected]>
Date: Tue, 16 Oct 2012 17:00:19 -0400
Subject: [PATCH] slab: Fix up stable merge of slab init_lock_keys()
There was a stable fix that moved the init_lock_keys() to after
the enable_cpucache(). But -rt changed this function to
init_cachep_lock_keys(). This moves the init afterwards to
match the stable fix.
Signed-off-by: Steven Rostedt <[email protected]>
---
mm/slab.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 119969a..27a194c 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1763,15 +1763,12 @@ void __init kmem_cache_init_late(void)
/* 6) resize the head arrays to their final sizes */
mutex_lock(&cache_chain_mutex);
list_for_each_entry(cachep, &cache_chain, next) {
- init_cachep_lock_keys(cachep);
if (enable_cpucache(cachep, GFP_NOWAIT))
BUG();
+ init_cachep_lock_keys(cachep);
}
mutex_unlock(&cache_chain_mutex);
- /* Annotate slab for lockdep -- annotate the malloc caches */
- init_lock_keys();
-
/* Done! */
g_cpucache_up = FULL;
--
1.7.10.4
On Thu, 2012-10-18 at 09:40 -0400, Steven Rostedt wrote:
> Peter,
>
> There was a little conflict with my merge of 3.4.14 due to the backport
> of this patch:
>
> commit 947ca1856a7e60aa6d20536785e6a42dff25aa6e
> Author: Michael Wang <[email protected]>
> Date: Wed Sep 5 10:33:18 2012 +0800
>
> slab: fix the DEADLOCK issue on l3 alien lock
>
> Could you just confirm that my fix is correct.
We forever keep getting that issue wrong it seems.. so I'd not put too
much trust into whatever my sleep addled brain thinks today :/
Looks about right, but who knows ;-)
On Fri, 19 Oct 2012, Peter Zijlstra wrote:
>> Could you just confirm that my fix is correct.
>
> We forever keep getting that issue wrong it seems.. so I'd not put too
> much trust into whatever my sleep addled brain thinks today :/
I wasn't expecting a reply till next week ;-)
>
> Looks about right, but who knows ;-)
>
Heh, OK, the worse thing that can happen is that I revert it for the next
-rt stable release. I wont hold off the releases to 3.2-rt and 3.4-rt over
this.
Thanks,
-- Steve