[PATCH] ppc64: Fix huge pages MMU mapping bug

Current kernel has a couple of sneaky bugs in the ppc64 hugetlb code that
cause huge pages to be potentially left stale in the hash table and TLBs
(improperly invalidated), with all the nasty consequences that can have.

One is that we forgot to set the "secondary" bit in the hash PTEs when
hashing a huge page in the secondary bucket (fortunately very rare).

The other one is on non-LPAR machines (like Apple G5s), flush_hash_range()
which is used to flush a batch of PTEs simply did not work for huge pages.
Historically, our huge page code didn't batch, but this was changed without
fixing this routine.  This patch fixes both.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

1 files changed, 2 insertions, 3 deletions

diff --git a/arch/ppc64/mm/hash_native.c b/arch/ppc64/mm/hash_native.c
index 7626bb59954d..eb1bbb5b6c16 100644
--- a/arch/ppc64/mm/hash_native.c
+++ b/arch/ppc64/mm/hash_native.c
@@ -343,9 +343,7 @@ static void native_flush_hash_range(unsigned long context,
         hpte_t *hptep;
         unsigned long hpte_v;
         struct ppc64_tlb_batch *batch = &__get_cpu_var(ppc64_tlb_batch);
-
-        /* XXX fix for large ptes */
-        unsigned long large = 0;
+        unsigned long large;
 
         local_irq_save(flags);
 
@@ -358,6 +356,7 @@ static void native_flush_hash_range(unsigned long context,
 
                 va = (vsid << 28) | (batch->addr[i] & 0x0fffffff);
                 batch->vaddr[j] = va;
+                large = pte_huge(batch->pte[i]);
                 if (large)
                         vpn = va >> HPAGE_SHIFT;
                 else