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.
Index: working-2.6/mm/hugetlb.c
===================================================================
--- working-2.6.orig/mm/hugetlb.c 2004-05-20 12:59:04.000000000 +1000
+++ working-2.6/mm/hugetlb.c 2004-06-02 12:14:53.582693952 +1000
@@ -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);
--
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
On Wed, Jun 02, 2004 at 12:23:12PM +1000, David Gibson wrote:
> 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