Fix MAP_WIREFUTURE leakage

[alc]

Summary

While reviewing the new stack management code, I observed that the MAP_WIREFUTURE flag is not cleared by exec_new_vmspace() when it recycles the current vmspace. Consequently, an mlockall(MCL_FUTURE) could still be in effect on the process after an {f,}execve(2). This violates the specification for mlockall(2).

Also, while I'm here, it's pointless for vm_map_stack() to check the MEMLOCK limit. It will never be asked to wire the stack. Moreover, it doesn't even implement wiring of the stack.

[kib]

With this change, vm_map_stack() becomes a check for vmemlim and call to vm_map_stack_locked(). The function has only one caller in execve(). Would it make sense to remove vm_map_stack() and call vm_map_fixed() from execve ?

[alc]

In D11421#236260, @kib wrote:

With this change, vm_map_stack() becomes a check for vmemlim and call to vm_map_stack_locked(). The function has only one caller in execve(). Would it make sense to remove vm_map_stack() and call vm_map_fixed() from execve ?

I think that the answer depends on how we deal with another edge-case bug. Observe that exec_new_vmspace() unconditionally initializes the vmspace's vm_ssize based on sgrowsiz. However, this may not be the actual, current stack size as implemented by vm_map_stack_locked(). One solution to this problem would be to return the initial stack size through an "out" parameter. None of the current callers of vm_map_fixed() really need such a parameter.

[kib]

In D11421#236321, @alc wrote:

In D11421#236260, @kib wrote:

With this change, vm_map_stack() becomes a check for vmemlim and call to vm_map_stack_locked(). The function has only one caller in execve(). Would it make sense to remove vm_map_stack() and call vm_map_fixed() from execve ?

I think that the answer depends on how we deal with another edge-case bug. Observe that exec_new_vmspace() unconditionally initializes the vmspace's vm_ssize based on sgrowsiz. However, this may not be the actual, current stack size as implemented by vm_map_stack_locked(). One solution to this problem would be to return the initial stack size through an "out" parameter. None of the current callers of vm_map_fixed() really need such a parameter.

I think I will leave it alone for now. In fact, it is probably more reasonable to handle it somewhat later after we rework the RLIM_STACK. If we start tracking the main thread stack mapping and relating gap(s), then vm_ssize could be naturally calculated as the size of the map entry.