Re: [bug] SLOB, tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot()

[Matt Mackall]

On Fri, Nov 30, 2007 at 10:14:18AM +0100, Ingo Molnar wrote:
> 
> * Matt Mackall <mpm@xxxxxxxxxxx> wrote:
> 
> > > plus, and this is a slob question i guess, how come we drop into 
> > > clear_highpage() for a kzalloc()??
> > 
> > Good question. Looks like kzalloc switched from doing a memset to
> > passing a GFP_ZERO flag down to kmalloc. Slob didn't get completely
> > updated to reflect this, so it blindly propagates the flag onto
> > __alloc_pages and does a harmless double-clear.
> > 
> > Someone should remind us what the point of moving the kzalloc memset
> > down into the allocators was. We now have all three allocators doing:
> > 
> >         if (unlikely((flags & __GFP_ZERO) && ptr))
> >                 memset(ptr, 0, obj_size(cachep));
> > 
> > and needing to mask flags before passing them to page allocators,
> > which hardly seems better than kzalloc unconditionally doing the
> > memset. Wouldn't it be better/faster/smaller to make kzalloc a
> > non-inline?
> > 
> > Slob also has a nice second path for large kmallocs where it just 
> > calls the page allocator directly which also needs this treatment. 
> > Which does the right thing with non-highmem systems, but can hit this 
> > bug otherwise.
> > 
> > Below is a totally untested patch. Alternately, we could simply tweak 
> > clear_highpage to remove the limitation, but that would leave slob 
> > doing an extra clear.
> 
> ok, this fixes the debug warning.
> 

But the question remains: is this the right fix? The commit in
question is here:

http://www.kernel.org/hg/linux-2.6/rev/13683609d67a

Christoph, remind us what's the upside here? It seems to me it would
be better to have separate non-inline kzalloc and kcalloc functions
that did the memset instead.

Another smaller open question is whether we want to remove the
in_interrupt restriction from clear_pagehigh.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/