Messages in this thread Patch in this message | | | Date | Thu, 13 Jul 2006 09:12:21 +0200 | From | Ingo Molnar <> | Subject | Re: Random panics seen in 2.6.18-rc1 |
| |
* 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); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |