[PATCH] (urgent) ppc32: Fix CPUs with soft loaded TLB

[Benjamin Herrenschmidt]

Hi !

The recent introduction of ptep_set_access_flags() with the optimisation
of not flushing the TLB unfortunately broke ppc32 CPUs with no hash table.

The data access exception code path in assembly for these doesn't properly
deal with the case where the TLB entry is present with the wrong PAGE_RW and
will just call do_page_fault again instead of just replacing the TLB entry.

Fixing the asm code for all the different CPU types affected (yah, embedded
PPCs all have different MMUs =P) is painful and need testing I can't do at
the moment, so here's a fix that will just flush the TLB page when changing
the access flags on non-hash based machines. Please apply.

Signed-off-by: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>

===== include/asm-ppc/pgtable.h 1.33 vs edited =====
--- 1.33/include/asm-ppc/pgtable.h	2004-05-26 09:56:17 -05:00
+++ edited/include/asm-ppc/pgtable.h	2004-06-06 16:02:27 -05:00
@@ -555,8 +555,12 @@
 		(_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW);
 	pte_update(ptep, 0, bits);
 }
+
 #define  ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
-        __ptep_set_access_flags(__ptep, __entry, __dirty)
+	do {								   \
+		__ptep_set_access_flags(__ptep, __entry, __dirty);	   \
+		flush_tlb_page_nohash(__vma, __address);	       	   \
+	} while(0)
 
 /*
  * Macro to mark a page protection value as "uncacheable".
===== arch/ppc/mm/tlb.c 1.10 vs edited =====
--- 1.10/arch/ppc/mm/tlb.c	2004-02-04 23:00:14 -06:00
+++ edited/arch/ppc/mm/tlb.c	2004-06-06 16:01:05 -05:00
@@ -67,6 +67,17 @@
 }
 
 /*
+ * Called by ptep_set_access_flags, must flush on CPUs for which the
+ * DSI handler can't just "fixup" the TLB on a write fault
+ */
+void flush_tlb_page_nohash(struct vm_area_struct *vma, unsigned long addr)
+{
+	if (Hash != 0)
+		return;
+	_tlbie(addr);
+}
+
+/*
  * Called at the end of a mmu_gather operation to make sure the
  * TLB flush is completely done.
  */


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/