On Sat, Dec 08, 2007 at 10:30:39AM +0100, Ingo Molnar wrote: > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > Subject : tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52 > > kmap_atomic_prot() > > Submitter : Ingo Molnar <[EMAIL PROTECTED]> > > References : http://lkml.org/lkml/2007/11/29/157 > > http://bugzilla.kernel.org/show_bug.cgi?id=9497 > > Handled-By : Matt Mackall <[EMAIL PROTECTED]> > > Patch : http://lkml.org/lkml/2007/11/29/387 > > Matt, the above bug is still occuring en masse during random bootups: >
I was hoping for some discussion about whether it was the best fix. The current kzalloc thing strikes me as a step backwards for all allocators. We'd do better to have a single non-inline kzalloc function rather than an extra branch in the normal kmalloc fast path. But here's the patch again, with my sign-off: Avoid calling page allocator with __GFP_ZERO, as we might be in atomic context and this will make thing unhappy on highmem systems. Instead, manually zero allocations from the page allocator. Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> diff -r f7edf7226317 mm/slob.c --- a/mm/slob.c Wed Dec 05 15:57:06 2007 -0600 +++ b/mm/slob.c Wed Dec 05 15:57:51 2007 -0600 @@ -223,6 +231,7 @@ static void *slob_new_page(gfp_t gfp, in { void *page; + gfp &= ~__GFP_ZERO; #ifdef CONFIG_NUMA if (node != -1) page = alloc_pages_node(node, gfp, order); @@ -457,6 +470,8 @@ void *__kmalloc_node(size_t size, gfp_t page = virt_to_page(ret); page->private = size; } + if (unlikely((gfp & __GFP_ZERO) && ret)) + memset(ret, 0, size); return ret; } } -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/