lkml.org 
[lkml]   [2008]   [Mar]   [29]   [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 Sat, 29 Mar 2008, Christoph Lameter wrote:
>
> > If SLUB *ever* calls the page allocator with __GFP_ZERO set, it's a
> > bug, and that has nothing to do with GFP_ATOMIC or anything else. Because
> > SLUB uses its own logic for clearing the result.
>
> Yes it uses its own logic if the object is managed by SLUB but not if the
> object is too big and/or the allocation forwarded to the page allocator
> or for other internal allocations of buffers etc.

Wrong.

It uses it's own logic for __GFP_ZERO *regardless* of size.

> > Why cannot you just admit it?
>
> Admitting something that is not true is rather difficult.

You don't have a f*cking clue about this cocde that you're supposed to be
maintaining, do you?

See "slab_alloc()". See the code:

if (unlikely((gfpflags & __GFP_ZERO) && object))
memset(object, 0, c->objsize);

and see how it does it regardless of anything else.

In short, if *any* code-path calls down to any allocator from that routine
with GFP_ZERO set, it's a bug. No ifs, buts or maybes about it. It
shouldn't do that, because the actual memset() is done by slab_alloc(),
and should not be done ANYWHERE ELSE.

It has *nothing* to do with "object is too big" or anything else.

> So what you want is to forbid any use of
>
> alloc_pages(__GFP_ZERO|...)

No. I want you to admit the bugs in code you maintain. I want you to admit
that slab_alloc() does the memset(), and should NEVER EVER use __GFP_ZERO
for the page allocations.

I have told you about a million times now that THIS HAS NOTHING TO DO WITH
interrupts or HIGHMEM or *anything* else. This is purely a SLUB issue.

But don't worry. I already fixed it by reverting your broken commit. I
just wish you could follow code that you are supposed to be maintaining.

Linus


\
 
 \ /
  Last update: 2008-03-29 22:33    [W:0.122 / U:0.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site