Re: [PATCH] Fixes for prep_zero_page

From: Zwane Mwaikambo
Date: Sun Jan 09 2005 - 16:33:04 EST


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;
}

-
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/