--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

hmm, actually this isn't an aliasing issue at all,
pmap_kremove() is just not flushing the cache.
note that when we remove the TTE entirely (such as in
pmap_page_protect(VM_PROT_NONE)), we do need to flush
the cache there as well.

please try the attached patch.

-Chuck


On Sun, Aug 25, 2002 at 06:14:21PM -0700, Andrey Petrov wrote:
> If there is a possibility of aliased mappings with different colors
> from a process and a kernel, then it's possible that process writes
> (and it goes to memory because cache is write-through) but kernel can
> access stalled cache line (which is not coherent) if it copies it.
> This somewhat explains why data corruption happens only over nfs.
> 
> Extra dcache_flush_page can trash cache contents (it flushes process' 
> page not kernel's, so it's not correct stalled cache line btw) and so
> occasionally invalidates it.
> 
> I have no proof for this schema, it's working scenario.
> 
> 	Andrey

--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="diff.sparc64-dcache.2"

Index: arch/sparc64/sparc64/pmap.c
===================================================================
RCS file: /cvsroot/syssrc/sys/arch/sparc64/sparc64/pmap.c,v
retrieving revision 1.125
diff -u -r1.125 pmap.c
--- arch/sparc64/sparc64/pmap.c	2002/08/12 12:04:31	1.125
+++ arch/sparc64/sparc64/pmap.c	2002/08/28 08:34:42
@@ -2006,6 +2006,8 @@
 {
 	struct pmap *pm = pmap_kernel();
 	int64_t data;
+	vaddr_t flushva = va;
+	vsize_t flushsize = size;
 	int i, s, flush = 0;
 
 	ASSERT(va < INTSTACK || va > EINTSTACK);
@@ -2084,6 +2086,7 @@
 #ifdef DEBUG
 		remove_stats.flushes ++;
 #endif
+		cache_flush_virt(flushva, flushsize);
 	}
 	simple_unlock(&pm->pm_lock);
 	splx(s);
@@ -3271,6 +3274,7 @@
 			}
 		}
 		splx(s);
+		dcache_flush_page(pa);
 	}
 	/* We should really only flush the pages we demapped. */
 	pv_check();

--LZvS9be/3tNcYl/X--