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