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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux