[lkml]   [2008]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.25-rc7-git2: Reported regressions from 2.6.24

    On Fri, 28 Mar 2008, Pekka Enberg wrote:
    > On Fri, Mar 28, 2008 at 6:00 AM, Linus Torvalds
    > <> wrote:
    > > And the fact is, passing in GFP_ZERO from the SLUB code is a bug
    > > regardless, because it unnecessarily does the dual memset().
    > We clear GFP_ZERO in new_slab() so the normal kmalloc()/kzalloc() path
    > should be fine but don't do it for kmalloc_large() nor
    > kmalloc_large_node(). Is that the bug here?

    Dammit, NO.

    The bug was that the commit I made (which was correct and robust) was then
    partially reverted by Christoph for no good reason. At that point,
    kmalloc_large() didn't even exist, so at that point the change was
    "technically correct" (since the only user of gfpflags really did end up
    clearing it somewhere deep in its callchain).

    So when that original 3811dbf67162bd08412f1b0e02e554f353e93bdb happened,
    it wasn't an outright bug - but that doesn't make it right. That commit
    was always just a bug waiting to happen, because it just set things up for
    later problems by retaining that bit when it really shouldn't have been
    retained, and forcing all future callers to be careful. Which they
    obviously were not!

    Yes, you can clear GFP_ZERO in multiple illogical places, and it will fix
    the bug. Or you can clear it in *one* place, that is in on the direct
    callchain from the person who actually does the memset(0), and even add a
    comment that says exactly what is going on.

    So the fact is, commit 3811dbf67162bd08412f1b0e02e554f353e93bdb is and was
    total and utter crap. I've reverted it in my tree. It's crap not because
    it was buggy when it was put in, but because it was *fragile* when it was
    put in. And that fragility ended up causing a bug later.

    I'm getting really tired of slub. It was supposed to be simpler code than
    slab, and yes, it's simpler, but it has been buggy as hell, and part of it
    has been that people just haven't been careful enough, and haven't written
    code to be defensive and easy-to-follow.

    So the *last* thing we want to do is to clear GFP_ZERO in multiple subtle
    places based on new random code being added. We want to clear it at the
    top level, so that no other code never ever even has to _think_ about it!


     \ /
      Last update: 2008-03-28 18:31    [W:0.021 / U:65.548 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site