[src/trunk]: src/sys/arch/arm/arm32 Apply some band-aid to pmap_activate() fo...

[scw <scw%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/810734fe9a58
branches:  trunk
changeset: 749382:810734fe9a58
user:      scw <scw%NetBSD.org@localhost>
date:      Sat Nov 28 11:44:45 2009 +0000

description:
Apply some band-aid to pmap_activate() for PR kern/41058:

There's a corner case here which can leave turds in the cache as
reported in kern/41058. They're probably left over during tear-down and
switching away from an exiting process. Until the root cause is identified
and fixed, zap the cache when switching pmaps. This will result in a few
unnecessary cache flushes, but that's better than silently corrupting data.

Also remove an extraneous return statement in pmap_page_protect() which
crept in during the matt-armv6 merge.

diffstat:

 sys/arch/arm/arm32/pmap.c |  24 +++++++++++++++++++++---
 1 files changed, 21 insertions(+), 3 deletions(-)

diffs (59 lines):

diff -r d8b5a7c54f4c -r 810734fe9a58 sys/arch/arm/arm32/pmap.c
--- a/sys/arch/arm/arm32/pmap.c Sat Nov 28 11:26:36 2009 +0000
+++ b/sys/arch/arm/arm32/pmap.c Sat Nov 28 11:44:45 2009 +0000
@@ -1,4 +1,4 @@
-/*     $NetBSD: pmap.c,v 1.202 2009/11/21 20:32:18 rmind Exp $ */
+/*     $NetBSD: pmap.c,v 1.203 2009/11/28 11:44:45 scw Exp $   */
 
 /*
  * Copyright 2003 Wasabi Systems, Inc.
@@ -211,7 +211,7 @@
 #include <machine/param.h>
 #include <arm/arm32/katelib.h>
 
-__KERNEL_RCSID(0, "$NetBSD: pmap.c,v 1.202 2009/11/21 20:32:18 rmind Exp $");
+__KERNEL_RCSID(0, "$NetBSD: pmap.c,v 1.203 2009/11/28 11:44:45 scw Exp $");
 
 #ifdef PMAP_DEBUG
 
@@ -3703,7 +3703,6 @@
            pg, VM_PAGE_TO_PHYS(pg), prot));
 
        switch(prot) {
-               return;
        case VM_PROT_READ|VM_PROT_WRITE:
 #if defined(PMAP_CHECK_VIPT) && defined(PMAP_APX)
                pmap_clearbit(pg, PVF_EXEC);
@@ -4124,6 +4123,15 @@
         * entire cache.
         */
        rpm = pmap_recent_user;
+
+/*
+ * XXXSCW: There's a corner case here which can leave turds in the cache as
+ * reported in kern/41058. They're probably left over during tear-down and
+ * switching away from an exiting process. Until the root cause is identified
+ * and fixed, zap the cache when switching pmaps. This will result in a few
+ * unnecessary cache flushes, but that's better than silently corrupting data.
+ */
+#if 0
        if (npm != pmap_kernel() && rpm && npm != rpm &&
            rpm->pm_cstate.cs_cache) {
                rpm->pm_cstate.cs_cache = 0;
@@ -4131,6 +4139,16 @@
                cpu_idcache_wbinv_all();
 #endif
        }
+#else
+       if (rpm) {
+               rpm->pm_cstate.cs_cache = 0;
+               if (npm == pmap_kernel())
+                       pmap_recent_user = NULL;
+#ifdef PMAP_CACHE_VIVT
+               cpu_idcache_wbinv_all();
+#endif
+       }
+#endif
 
        /* No interrupts while we frob the TTB/DACR */
        oldirqstate = disable_interrupts(IF32_bits);