Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB

[Paul Mundt <lethal@linux-sh.org>]

On Sun, Jun 01, 2008 at 10:58:34AM +0300, Pekka Enberg wrote:
> Paul Mundt wrote:
> >Not until the page->index bits are killed, otherwise you aren't fixing
> >anything. SLOB on nommu with those page->index tests will automatically
> >oops today, before or after your patches. Until that's resolved, there's
> >no point in pretending like kobjsize() has been "fixed". As no one has
> >come up with a valid reason for those tests existing in the first place,
> >simply having your patches and killing the BUG_ON()'s seems ok.
> 
> Sorry if I'm starting to sound like a broken record, but can you explain 
> why removing the ->index bits are safe? I mean, if removing them is 
> really okay, that means we don't hit that code path with SLAB at all?
> 
I thought I already had several times, but I'll attempt to summarize again..

I would expect the only reason those BUG_ON()'s haven't been triggered in
the non-SLOB case is due to the fact PageSlab() takes a different path
out.

The page->index bits look like they are being used for determining
compound order, which is _completely_ bogus, and only happens to "work"
in a few cases. Christoph and I have repeatedly asked for someone to
explain what the hell those tests are there for, as right now they not
only look completely bogus, but they also stop us from booting on SLOB.
So far no one has provided any input on why those page->index BUG_ON()'s
have any right to exist.

So while having 2 out of 3 SLAB allocators in a bootable state might seem
like progress, I'd rather see kobjsize() fixed correctly. Even my initial
patches worked for all 3.

If no one can speak up to defend those bits, they should be killed off
before 2.6.26. Whether this is done in combination with your patch or
Christoph's patch or whatever else doesn't matter.