[PATCH] memcgroup: check and initialize page->cgroup in memmap_init_zone

From: Shi Weihua
Date: Thu Apr 17 2008 - 22:47:36 EST


When we test memory controller in Fujitsu PrimeQuest(arch: ia64),
the compiled kernel boots failed, the following message occured on
the telnet terminal.
-------------------------------------
..........
ELILO boot: Uncompressing Linux... done
Loading file initrd-2.6.25-rc9-00067-gb87e81e.img...done
_ (system freezed)
-------------------------------------

We found commit 9442ec9df40d952b0de185ae5638a74970388e01
causes this boot failure by git-bisect.
And, we found the following change caused the boot failure.
-------------------------------------
@@ -2528,7 +2535,6 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zon
set_page_links(page, zone, nid, pfn);
init_page_count(page);
reset_page_mapcount(page);
- page_assign_page_cgroup(page, NULL);
SetPageReserved(page);

/*
-------------------------------------
In this patch, the Author Hugh Dickins said
"...memmap_init_zone doesn't need it either, ...
Linux assumes pointers in zeroed structures are NULL pointers."
But it seems it's not always the case, so we should check and initialize
page->cgroup anyways.

Signed-off-by: Shi Weihua <shiwh@xxxxxxxxxxxxxx>
---
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 402a504..506d4cf 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2518,6 +2518,7 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
struct page *page;
unsigned long end_pfn = start_pfn + size;
unsigned long pfn;
+ void *pc;

for (pfn = start_pfn; pfn < end_pfn; pfn++) {
/*
@@ -2535,6 +2536,9 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
set_page_links(page, zone, nid, pfn);
init_page_count(page);
reset_page_mapcount(page);
+ pc = page_get_page_cgroup(page);
+ if (pc)
+ page_reset_bad_cgroup(page);
SetPageReserved(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/