Subject: panic: pv_unlink0 - some simple questions about sparc pmap code
To: None <port-sparc@NetBSD.ORG>
From: Erik E. Fair <fair@clock.org>
List: port-sparc
Date: 05/28/1997 03:50:50
Why doesn't pv_unlink4m() simply return when pv_pmap == NULL?
Nearly all its counterparts do.
Why isn't "pv_va" a "vm_offset_t" (unsigned long) instead of an "int"?
Most other ports appear to have it defined this way.
I've got more code reading to do, but my impression is as follows:
1. the pv_table stuff is a software-only table of pages that have mappings,
possibly multiple mappings, hence the singly linked list, and the pmap
structure pointers.
2. the kernel portion of the pv_table is probably not properly initialized
since the kernel page tables are hand-built in the first place in
pmap_bootstrap() and pmap_init() (when I dumped the entire 24,000 entry
table after a recent crash, fully 60% of the entries had virtual addresses,
but no pmap pointer).
3. when pmap_enk4m() goes down to rewire things for a new (or perhaps
reusing a freed allocation that was previously used) kernel malloc, panic
in pv_unlink4m() because the pv_table is not quite set up right for the
kernel (i.e. pv_pmap == NULL). Boom.
Thanks for any insight that can be provided,
Erik