[lkml]   [2007]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] [PATCH] cpuset operations causes Badness at mm/slab.c:777 warning

    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).


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-02 01:29    [W:0.031 / U:2.420 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site