Subject: port-i386/5291: i386 pmap_remove_all bug
To: None <gnats-bugs@gnats.netbsd.org>
From: David Holland <dholland@eecs.harvard.edu>
List: netbsd-bugs
Date: 04/14/1998 06:27:13
>Number:         5291
>Category:       port-i386
>Synopsis:       pmap_remove_all leaves garbage reverse mappings
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 14 03:50:00 1998
>Last-Modified:
>Originator:     David A. Holland <dholland@eecs.harvard.edu>
>Organization:
   - David A. Holland             |    VINO project home page:
     dholland@eecs.harvard.edu    | http://www.eecs.harvard.edu/vino
>Release:        1.3
>Environment:
	
This affects the 1.3 release and also appears to remain in -current as
of this morning.

>Description:

	When pmap_remove_all is called on a physical address with
	multiple mappings, the linked list of pv_entries isn't 
	cleaned up properly, with the result that it becomes
	crosslinked to one of the pv_entry free lists. This results
	in other pv_entries ending up on several pages' pv_table
	lists, and generally makes a grand mess. 

	I think it's a non-fatal mess; either that or it never 
	happens in NetBSD's vm system or somebody would have 
	noticed by now...

>How-To-Repeat:
	n/a, unless you want to build vino, in which case it
	panics after a few minutes of operation.

>Fix:
	Apply the following patch:

--- pmap.c	Tue Apr 14 06:15:18 1998
+++ pmap.c.fixed	Tue Apr 14 06:15:50 1998
@@ -1084,16 +1084,17 @@
 
 		npv = pv->pv_next;
 		if (pv == ph)
 			ph->pv_pmap = NULL;
 		else
 			pmap_free_pv(pv);
 		pv = npv;
 	}
+	ph->pv_next = NULL;
 	splx(s);
 
 	pmap_update();
 }
 
 /*
  *	Set the physical protection on the
  *	specified range of this map as requested.
>Audit-Trail:
>Unformatted: