![]() | |||||||||||||
Messages in this thread
Patch in this message |
On Sat, Dec 08, 2007 at 10:30:39AM +0100, Ingo Molnar wrote: > > * Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > Subject : tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52 kmap_atomic_prot() > > Submitter : Ingo Molnar <mingo@elte.hu> > > References : http://lkml.org/lkml/2007/11/29/157 > > http://bugzilla.kernel.org/show_bug.cgi?id=9497 > > Handled-By : Matt Mackall <mpm@selenic.com> > > 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 <mpm@selenic.com> 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. | ||||||||||||
| Last update: 2007-12-08 17:41 [from the cache] ©2003-2008 | |||||||||||||