:This patch is the start of mlockall/munlockall support; it adds a
:field to each vm_map, flags, to support mlockall(MCL_FUTURE) {from
:FreeBSD} and modifies mmap() and brk() to test for that flag and wire
:in any newly ill-gotten pages. It also implements munlockall(). This
:code has been tested in a vkernel, seems to work okay.
:
:Questions:
:1) what permissions do we want to check for mlockall()?
Either root-only or there needs to be some sort of resource limit
on non-root processes on the number of pages which can be locked.
:2) current, I read the vm_map flags under the per-map lock. this is
:probably overkill for mmap and brk; should I read the value directly
:instead?
For reading the flag only you do not need the lock.
Hmm. for mmap/brk it may be better to just have the vm_map code check
the map flag itself and automatically wire the memory instead of having
the upper level callers check the flag and take an extra step.
:3) in munlockall(), I've marked a section 'XXX', where it might be
:possible to hit an in-transition map entry (entry->eflags ==
:MAP_ENTRY_IN_TRANSITION). I don't understand places in the vm where
:that is tested for and the map lock released around it... I didn't see
:any place where that was set and the per-map lock released afterwards,
:perhaps I'm missing something?
I think you do have to check. I suggest looking at the code for
vm_map_delete() as a reference point.
:4) are automatic stack growth pages supposed to be affected by MCL_FUTURE?
Yes.
:5) are pages from the 43bsd compat code supposed to be affected by MCL_FUTURE?
Yes, though if you rearrange the code to have the vm_map module deal
with the flag itself instead of the callers this will be handled
automatically.
-Matt