On Tue, Jan 11, 2011 at 03:04:21PM +0100, Andrea Arcangeli wrote:
> architectural bug to me. Why can't pud_huge simply return 0 for
> x86_32? Any other place dealing with hugepages and calling pud_huge on
> x86 noPAE would be at risk, otherwise, no?
Isn't this better solution?
======
Subject: avoid confusing hugetlbfs code when pmd_trans_huge is set
From: Andrea Arcangeli <aarcange@xxxxxxxxxx>
If pmd is set huge by THP, pud_huge shouldn't return 1 when pud doesn't exist
and it's just a 1:1 bypass over the pmd (like it happens on 32bit x86 because
there are at most 2 or 3 level of pagetables). Only pmd_huge can return 1.
Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx>
---
diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -227,7 +227,15 @@ int pmd_huge(pmd_t pmd)
int pud_huge(pud_t pud)
{
+#ifdef CONFIG_X86_64
return !!(pud_val(pud) & _PAGE_PSE);
+#else
+ /*
+ * pud is a bypass with 2 or 3 level pagetables, only pmd_huge
+ * can return 1.
+ */
+ return 0;
+#endif
}
struct page *
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>