Skip to contentSkip to conversation

Hugepage bugfix

PATCH David Gibson 2 participants 2 messages Jun 2, 2004

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Andrew, please apply:

Currently the hugepage code stores the hugepage destructor in the mapping field of the second of the compound pages. However, this field is never cleared again, which causes tracebacks from free_pages_check() if the hugepage is later destroyed by reducing the number in /proc/sys/vm/nr_hugepages. This patch fixes the bug by clearing the mapping field when the hugepage is freed.

mm/hugetlb.c +1 -0
Index: working-2.6/mm/hugetlb.c
===================================================================
@@ -57,6 +57,7 @@
 	BUG_ON(page_count(page));
 
 	INIT_LIST_HEAD(&page->lru);
+	page[1].mapping = NULL;
 
 	spin_lock(&hugetlb_lock);
 	enqueue_huge_page(page);
Signature · 4 lines
David Gibson			| For every complex problem there is a
david AT gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson
#1 lore raw
Quoted 6 lines · David Gibson

Currently the hugepage code stores the hugepage destructor in the mapping field of the second of the compound pages. However, this field is never cleared again, which causes tracebacks from free_pages_check() if the hugepage is later destroyed by reducing the number in /proc/sys/vm/nr_hugepages. This patch fixes the bug by clearing the mapping field when the hugepage is freed.

Good catch; thanks.

-- wli