When hugepages are newly allocated to a file in mm/hugetlb.c, we clear
them with a call to clear_highpage() on each of the subpages. We
should be using clear_user_highpage(): on powerpc, at least,
clear_highpage() doesn't correctly mark the page as icache dirty so if
the page is executed shortly after it's possible to get strange
results.
This is a bugfix and should go into 2.6.16.
Signed-off-by: David Gibson <[email protected]>
Index: working-2.6/mm/hugetlb.c
===================================================================
--- working-2.6.orig/mm/hugetlb.c 2006-02-06 12:58:07.000000000 +1100
+++ working-2.6/mm/hugetlb.c 2006-02-06 12:58:19.000000000 +1100
@@ -107,7 +107,7 @@ struct page *alloc_huge_page(struct vm_a
set_page_count(page, 1);
page[1].mapping = (void *)free_huge_page;
for (i = 0; i < (HPAGE_SIZE/PAGE_SIZE); ++i)
- clear_highpage(&page[i]);
+ clear_user_highpage(&page[i], addr);
return page;
}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
On Mon, Feb 06, 2006 at 01:18:53PM +1100, David Gibson wrote:
> When hugepages are newly allocated to a file in mm/hugetlb.c, we clear
> them with a call to clear_highpage() on each of the subpages. We
> should be using clear_user_highpage(): on powerpc, at least,
> clear_highpage() doesn't correctly mark the page as icache dirty so if
> the page is executed shortly after it's possible to get strange
> results.
> This is a bugfix and should go into 2.6.16.
> Signed-off-by: David Gibson <[email protected]>
Not sure how this got past the usual crapfilters. Sorry about that.
Acked-by: William Irwin <[email protected]>
-- wli