Re: mlockall / munlockall patch

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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