Excerpts from netbsd: 13-Feb-98 Re: (old) vm problem: is th.. Ignatios
Souvatzis@theor (352*)

[patch to vm_fault.c]

> IMO, you should not touch the pmap wiring at all. If you need it explicitly
> wired for that time, restore it to the old value afterwards, not to unwired.

At least in the situation which leads to a panic, the page
is definitely not present in the kernel's pmap before. It is
explicitely mapped and wired in procfs_rwmem().


It looks normal and intended to me that the pmap's wiring is
changed from vm_fault_unwire() - as long as managed pages
are concerned. vm_fault() always allocates managed pages -
the ugly thing is the design of the device pager which turns
managed pages into unmanaged ones behind vm_fault's back.
Imho, the unwiring should be controlled by the pager too
(or better: vm_fault() should not allocate the pages before the
pager comes into the game so that all the "fake page" stuff is
unnecessary).
UVM does better as it looks.

Another solution to my "panic" problem would be to
catch mmap()ed pages early in procfs_rwmem() (similar
to the check in vm_coredump()) and refuse to read data
from them. This would even be saver because problems with
side effects on device accesses are avoided. Otoh, it's
not nice to dig into vm_object's internals in code outside of
sys/vm. (UVM has arranged it cleaner. It does not catch
accesses to device memory yet, but this is another problem.)

best regards
Matthias