Comments about vm_fault, vm_map_lookup and user-wired memory, part 1

Andrey Simonenko simon at comsys.ntu-kpi.kiev.ua
Thu Mar 31 03:03:30 PST 2005


Greetings,

I have two questions or comments about of user-wired memory
(system 5.3).

First question.  If memory is user-wired, read-only and COW,
then it is impossible to change protection for this memory:

1. mprotect() calls vm_map_protect(), which change entry->protection
   to writeable.

2. When write page fault occurs for this memory, vm_fault() calls
   vm_map_lookup(), which notices that entry->protection allows
   write to this memory (first if() statement in vm_map_lookup()),
   but, then it does not allow write page fault, since flag
   VM_PROT_OVERRIDE_WRITE is not set, since this is a normal page
   fault from a process.  As the result, we have KERN_PROTECTION_FAILURE.

   From the other side, if this user-wired (now read-write after
   mprotect() call) and COW memory is modified by debugger, which
   uses VM_PROT_OVERRIDE_WRITE or'ed with VM_PROT_WRITE, then
   vm_map_lookup() creates shadow object, which shadows original
   memory and new page is created in the new shadow object.  Since
   vm_fault() was called without any *WIRE* bit, then new page
   in the shadow object becomes unwired.

   Then when process which has user-wired memory exits, vm_map_unwire()
   is called for a page in that shadow object, since its vm_entry has
   wired_count greater than 0, since new page for the shadow object was
   not wired we get panic from vm_page_unwire(), since vm_map_delete()
   -> vm_map_entry_unwire() -> vm_fault_unwire() does not expect to see
   shadow objects for wired vm_entry
   
   When another process exits we get panic in vm_page_free() from
   vm_object_backing_scan(), when shadow object and original object in
   a process with user-wired memory are collapsed in vm_object_collapse(),
   since shadow object has copy of a page of user-wired page,
   vm_object_backing_scan() frees wired page.

Here is my question: why it is not allowed to change protection of user-
wired, r/o and COW memory?  If it is not allowed to create shadow objects
for wired memory for the same process, why they are created with the help
from the debugger?  Note, that such behavior causes panic, because
some parts of the VM system are not aware of shadow object for objects
with user-wired pages.

Second question in the next letter.


More information about the freebsd-hackers mailing list