hugetlb: preserve hugetlb pte dirty state

["Ken Chen" <kenchen@google.com>]

__unmap_hugepage_range() is buggy that it does not preserve dirty
state of huge_pte when unmapping hugepage range.  It causes data
corruption in the event of dop_caches being used by sys admin.
For example, an application creates a hugetlb file, modify pages,
then unmap it.  While leaving the hugetlb file alive, comes along
sys admin doing a "echo 3 > /proc/sys/vm/drop_caches".
drop_pagecache_sb() will happily frees all pages that isn't marked
dirty if there are no active mapping. Later when application remaps
the hugetlb file back and all data are gone, triggering catastrophic
flip over on application.

Not only that, the internal resv_huge_pages count will also get all
messed up.  Fix it up by marking page dirty appropriately.

Signed-off-by: Ken Chen <kenchen@google.com>

--- ./mm/hugetlb.c.orig	2007-02-06 08:28:33.000000000 -0800
+++ ./mm/hugetlb.c	2007-02-06 08:29:47.000000000 -0800
@@ -389,6 +389,8 @@
 			continue;

 		page = pte_page(pte);
+		if (pte_dirty(pte))
+			set_page_dirty(page);
 		list_add(&page->lru, &page_list);
 	}
 	spin_unlock(&mm->page_table_lock);
--- ./fs/hugetlbfs/inode.c.orig	2007-02-06 08:29:56.000000000 -0800
+++ ./fs/hugetlbfs/inode.c	2007-02-06 08:40:44.000000000 -0800
@@ -449,10 +449,13 @@
 }

 /*
- * For direct-IO reads into hugetlb pages
+ * mark the head page dirty
  */
 static int hugetlbfs_set_page_dirty(struct page *page)
 {
+	struct page *head = (struct page *) page_private(page);
+
+	SetPageDirty(head);
 	return 0;
 }

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>