Re: Random panics seen in 2.6.18-rc1

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> wrote:

> On Thu, 13 Jul 2006 09:12:21 +0200
> Ingo Molnar <mingo@xxxxxxx> wrote:
> 
> > 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.
> > 
> 
> yup.
> 
> > ---
> >  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);
> 
> But what was that change _for_?  Presumably, to plug some lockdep 
> problem. Which now will come back.

correct - but i first wanted to get the fix out, before trying to fix 
the lockdep thing.

> And the additional arg to __cache_free() was rather a step backwards - 
> this is fastpath.  With a bit more effort that could have been avoided 
> (please).

yeah, i'll fix this. Any suggestions of how to avoid the parameter 
passing? (without ugly #ifdeffery)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/