Re: [PATCH] slab: fix offslab_limit in calculate_slab_order (Was: Slab corruption in 2.6.16-rc5-mm2)

[Pekka Enberg <penberg@cs.helsinki.fi>]

On Tue, 7 Mar 2006, Pekka J Enberg wrote:
> > No you're not, it's broken. However, I think you're forgetting to reset 
> > cachep->num when we go over MAX_GFP_ORDER, no?

On Tue, 2006-03-07 at 09:12 -0800, Linus Torvalds wrote:
> No, we only ever set "cachep->num" for something that we've decided is 
> valid.
> 
> "gfporder" can never be > MAX_GFP_ORDER inside the loop, because we just 
> iterate between 0..MAX_GFP_ORDER.

I don't think that's true. We set cachep->num to something we think is
valid but check for internal fragmentation later. So I think we can get
out of the loop with cachep->num initialized to non-zero but gfporder
set to MAX_GFP_ORDER, no? Or did I forget to take my medicine this
morning...?

			Pekka

-
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/