Re: Random panics seen in 2.6.18-rc1

[Ingo Molnar <mingo@elte.hu>]

* Chandra Seetharaman <sekharan@us.ibm.com> wrote:

> By adding one patch at a time to 2.6.17's mm/slab.c, I found that the
> following patch is the cause of the panic.
> --------------
> [PATCH] lockdep: annotate SLAB code

great debugging!

I have reviewed that patch, and there's only one chunk that could 
possibly have a functional effect. The patch below undoes it - does that 
fix the crashes you are seeing? [If you have lockdep enabled then this 
patch will cause a lockdep false positive - ignore that one for now, it 
shouldnt impact the crash scenario itself.]

	Ingo

--------------------->
Subject: revert slab.c locking change
From: Ingo Molnar <mingo@elte.hu>

Chandra Seetharaman reported SLAB crashes caused by the slab.c
lock annotation patch. There is only one chunk of that patch
that has a material effect on the slab logic - this patch
undoes that chunk.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 mm/slab.c |    9 ---------
 1 file changed, 9 deletions(-)

Index: linux/mm/slab.c
===================================================================
--- linux.orig/mm/slab.c
+++ linux/mm/slab.c
@@ -3100,16 +3100,7 @@ static void free_block(struct kmem_cache
 		if (slabp->inuse == 0) {
 			if (l3->free_objects > l3->free_limit) {
 				l3->free_objects -= cachep->num;
-				/*
-				 * It is safe to drop the lock. The slab is
-				 * no longer linked to the cache. cachep
-				 * cannot disappear - we are using it and
-				 * all destruction of caches must be
-				 * serialized properly by the user.
-				 */
-				spin_unlock(&l3->list_lock);
 				slab_destroy(cachep, slabp);
-				spin_lock(&l3->list_lock);
 			} else {
 				list_add(&slabp->list, &l3->slabs_free);
 			}