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: