[PPC64] Hugepage hash flushing bugfix

[PPC64] Hugepage hash flushing bugfix

[David Gibson]

Andrew, Linus, please apply:

Fix a potentially bad (although very rarely triggered) bug in the
ppc64 hugepage code.  hpte_update() did not correctly calculate the
address for hugepages, so pte_clear() (which we use for hugepage ptes
as well as normal ones) would not correctly flush the hash page table
entry.  Under the right circumstances this could potentially lead to
duplicate hash entries, which is very bad.

davem's upcoming patch to pass the virtual address directly to
set_pte() and its ilk will obsolete this, but this is bad enough it
should probably be fixed in the meantime.

Signed-off-by: David Gibson <dwg@au1.ibm.com>

Index: working-2.6/arch/ppc64/mm/tlb.c
===================================================================
--- working-2.6.orig/arch/ppc64/mm/tlb.c	2004-09-09 09:59:49.000000000 +1000
+++ working-2.6/arch/ppc64/mm/tlb.c	2005-02-25 14:56:47.000000000 +1100
@@ -85,8 +85,12 @@
 
 	ptepage = virt_to_page(ptep);
 	mm = (struct mm_struct *) ptepage->mapping;
-	addr = ptepage->index +
-		(((unsigned long)ptep & ~PAGE_MASK) * PTRS_PER_PTE);
+	addr = ptepage->index;
+	if (pte_huge(pte))
+		addr +=  ((unsigned long)ptep & ~PAGE_MASK)
+			/ sizeof(*ptep) * HPAGE_SIZE;
+	else
+		addr += ((unsigned long)ptep & ~PAGE_MASK) * PTRS_PER_PTE;
 
 	if (REGION_ID(addr) == USER_REGION_ID)
 		context = mm->context.id;


-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist.  NOT _the_ _other_ _way_
				| _around_!
http://www.ozlabs.org/people/dgibson

Re: [PPC64] Hugepage hash flushing bugfix

[William Lee Irwin III]

On Fri, Feb 25, 2005 at 03:14:46PM +1100, David Gibson wrote:
> Andrew, Linus, please apply:
> Fix a potentially bad (although very rarely triggered) bug in the
> ppc64 hugepage code.  hpte_update() did not correctly calculate the
> address for hugepages, so pte_clear() (which we use for hugepage ptes
> as well as normal ones) would not correctly flush the hash page table
> entry.  Under the right circumstances this could potentially lead to
> duplicate hash entries, which is very bad.
> davem's upcoming patch to pass the virtual address directly to
> set_pte() and its ilk will obsolete this, but this is bad enough it
> should probably be fixed in the meantime.
> Signed-off-by: David Gibson <dwg@au1.ibm.com>

Very clear explanation. I second the motion for a rapid merge.

Acked-by: William Irwin <wli@holomorphy.com>