Re: [RFC] [PATCH] cpuset operations causes Badness at mm/slab.c:777 warning

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 1 Jun 2007, Andrew Morton wrote:
> 
> We could store the size of the allocation in the allocated object?  Just
> add four bytes to the user's request, then pick the appropriate cache based
> on that, then put the user's `size' at the tail of the resulting allocation?

It should be easy enough to do it for _most_ allocations by just doing it 
when there is already "enough slack" to do it (which is likely true most 
of the time).

IOW, if you ask for a 42-byte allocation, and we allocate from a 64-byte 
slab, you get the slab allocation at address X, you don't actually have to 
return "X" at all. Just return "X+8", and then you do:

 - at 32-bit word at X+0 you put the "real length"
 - at 32-bit word at X+4 you put some good redzone marker
 - at 32-bit word at "X + reallen + 8" you put the endzone marker.

And then you say: if the real length was within 12 bytes of the allocation 
length, we just don't do this.

So you wouldn't get any redzoning for those allocations that are exactly 
sized (or close enough) to fit in an allocation block, but I bet *most* 
allocations would get this for free.

And then, if you actually turn on redzoning, you just always add the 12 
byte to the allocation size (assuming the alignment rules allow you to).

The nice thing about this is that the freeing path already knows where the 
object is *supposed* to start (because it sees the allocation size in the 
slub/slab data structures), so the kfree() path can actually figure out on 
its own whether it is given a "X" or an "X+8" kind of address.

So you don't actually need any extra information. You literally just need 
enough slop in the allocation that you can do this in the first place, so 
there is no cost (except for the cost of checking itself, of course).

Hmm?

			Linus