Re: Random panics seen in 2.6.18-rc1

[Andrew Morton <akpm@osdl.org>]

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.

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).