Messages in this thread | | | Date | Thu, 13 Jul 2006 09:26:35 +0200 | From | Ingo Molnar <> | Subject | Re: Random panics seen in 2.6.18-rc1 |
| |
* Andrew Morton <akpm@osdl.org> wrote:
> On Thu, 13 Jul 2006 09:12:21 +0200 > Ingo Molnar <mingo@elte.hu> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |