Messages in this thread | | | Date | Sat, 29 Mar 2008 14:29:27 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 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
| |