Yet another hugepage bug

Yet another hugepage bug

[David Gibson]

Andrew, please apply

Currently, calling msync() on a hugepage area will cause the kernel to
blow up with a bad_page() (at least on ppc64, but I think the problem
will exist on other archs too).  The msync path attempts to walk
pagetables which may not be there, or may have an unusual layout for
hugepages.

Lucikly we shouldn't need to do anything for an msync on hugetlbfs
beyond flushing the cache, so this patch should be sufficient to fix
the problem.

Index: working-2.6/mm/msync.c
===================================================================
--- working-2.6.orig/mm/msync.c	2004-05-20 12:59:04.000000000 +1000
+++ working-2.6/mm/msync.c	2004-06-02 17:33:50.775695368 +1000
@@ -11,6 +11,7 @@
 #include <linux/pagemap.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
+#include <linux/hugetlb.h>
 
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
@@ -106,6 +107,13 @@
 
 	dir = pgd_offset(vma->vm_mm, address);
 	flush_cache_range(vma, address, end);
+
+	/* For hugepages we can't go walking the page table normally,
+	 * but that's ok, hugetlbfs is memory based, so we don't need
+	 * to do anything more on an msync() */
+	if (is_vm_hugetlb_page(vma))
+		goto out;
+
 	if (address >= end)
 		BUG();
 	do {
@@ -118,7 +126,7 @@
 	 * dirty bits.
 	 */
 	flush_tlb_range(vma, end - size, end);
-
+ out:
 	spin_unlock(&vma->vm_mm->page_table_lock);
 
 	return error;


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