lkml.org 
[lkml]   [2008]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
> <torvalds@linux-foundation.org> 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!

Linus


\
 
 \ /
  Last update: 2008-03-28 18:31    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site