Re: [PATCH] Fixes for prep_zero_page

[Zwane Mwaikambo <zwane@arm.linux.org.uk>]

On Sun, 9 Jan 2005, Andrew Morton wrote:

> This won't work right if someone tries to allocate memory while holding a
> KM_IRQ0 atomic kmap.
> 
> It would be quite bizarre for anyone to be allocating highmem pages from
> IRQ context anyway, but as a generic mechanism this really should work as
> expected in all contexts.  That means a new kmap slot.

I was trying to find users of nested KM_IRQ to verify against so i just 
went with the first slot. The problem with sharing a slot with irq context 
is that you have to exclude interrupts whilst doing the zeroing too, 
unless we maybe create two slots.

> Can't we simply move the page zeroing to the very end of __alloc_pages()?

Ok, i've changed that bit to something like;

Index: linux-2.6.10-mm2/mm/page_alloc.c
===================================================================
RCS file: /home/cvsroot/linux-2.6.10-mm2/mm/page_alloc.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 page_alloc.c
--- linux-2.6.10-mm2/mm/page_alloc.c	9 Jan 2005 04:52:40 -0000	1.1.1.1
+++ linux-2.6.10-mm2/mm/page_alloc.c	9 Jan 2005 21:23:31 -0000
@@ -732,9 +740,6 @@ buffered_rmqueue(struct zone *zone, int 
 		mod_page_state_zone(zone, pgalloc, 1 << order);
 		prep_new_page(page, order);
 
-		if (gfp_flags & __GFP_ZERO)
-			prep_zero_page(page, order);
-
 		if (order && (gfp_flags & __GFP_COMP))
 			prep_compound_page(page, order);
 	}
@@ -935,6 +940,8 @@ nopage:
 got_pg:
 	zone_statistics(zonelist, z);
 	kernel_map_pages(page, 1 << order, 1);
+	if (gfp_mask & __GFP_ZERO)
+		prep_zero_page(page, order);
 	return page;
 }