[lkml]   [2008]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Redzone overwritten with CONFIG_SECURITY

    On Tue, May 27, 2008 at 4:00 PM, Eric Sesterhenn <> wrote:
    > hi,
    > i tested a kmemcheck kernel as an attempt to debug
    > this further... seems CONFIG_SECURITY is unrelated to
    > this, but slub debugging only catches the
    > overwrite it if i enable CONFIG_SECURITY.

    Oy, whow! :-)

    I actually tried to reproduce your problem yesterday to see if
    kmemcheck would catch it, but I couldn't reproduce it, so I gave up

    > with slub_debug=FZPU i get the warning at
    > init_object+0x63:
    > (gdb) l *(init_object+0x63)
    > 0xc0187243 is in init_object (mm/slub.c:544).
    > 539 {
    > 540 u8 *p = object;
    > 541
    > 542 if (s->flags & __OBJECT_POISON) {
    > 543 memset(p, POISON_FREE, s->objsize - 1);
    > 544 p[s->objsize - 1] = POISON_END;
    > 545 }
    > 546
    > 547 if (s->flags & SLAB_RED_ZONE)
    > 548 memset(p + s->objsize,

    This is sort of expected. kmemcheck is not directly incompatible with
    slub debugging, but it may produce some false positives (that we
    haven't worked out yet). So I recommend that you turn slub debugging
    off, like you did below.

    > if i set slub_debug=- i get the kmemcheck warning at
    > (gdb) l *(__slab_alloc+0x238)
    > 0xc0187bc8 is in __slab_alloc (mm/slub.c:303).
    > 298 return *(void **)(object + s->offset);
    > 299 }
    > 300
    > 301 static inline void set_freepointer(struct kmem_cache *s, void
    > *object, void *fp)
    > 302 {
    > 303 *(void **)(object + s->offset) = fp;
    > 304 }
    > 305
    > 306 /* Loop over all objects in a slab */
    > 307 #define for_each_object(__p, __s, __addr, __objects) \

    Hm, yes. It would be nice to see the actual kmemcheck error message as
    well in order to determine the cause of this.

    I don't really see how that write (= fp) can cause an error, so it has
    to be the s->offset dereference that is doing it. That seems extremely
    unlikely and would indicate a bug in SLUB itself...

    Out of curiosity, will your crash go away entirely if you compile the
    kernel using SLAB?

    > I used the kmemcheck git tree from
    > git://
    > In case you need some of the other kmemcheck output please
    > let me know.

    It would be nice to see the whole dmesg if you can get it.

    You should also make sure you have either


    set in your config or that you are booting with the kmemcheck=1
    command-line option; otherwise, you'll only get the first warning
    before kmemcheck auto-disables itself. Forcing it to stay on will
    potentially give us more useful output.

    There is actually a newer kmemcheck tree which supports
    kmemcheck+SLAB, but the version you are running should be usable for
    debugging your problem, so I'm not going to ask you to try that.

    Thanks for trying it out, it would feel good if kmemcheck would
    finally be useful for something :-) Good luck.


    "The animistic metaphor of the bug that maliciously sneaked in while
    the programmer was not looking is intellectually dishonest as it
    disguises that the error is the programmer's own creation."
    -- E. W. Dijkstra, EWD1036

     \ /
      Last update: 2008-05-27 16:27    [W:0.050 / U:1.156 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site