bug #15403 : can't mlock mmap'd memory

[Samuel Thibault]

Hi,

It seems that the bug#15403[1] reply didn't get CCed to bug-hurd, so
here it is:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=15403

===

Some tests seem to show that only stacked objects can be mlock()ed.

Mlock() is implemented through vm_wire(blabla, VM_PROT_ALL): `Specify
that the range of the virtual address space of the target task must not
cause page faults for the indicated accesses.'

This is wrong: doing it on text segments can't work for instance,
since page-write faults must still occur on them (since they're
read-only). Same remark for data segments / executability,
etc. The actual check is performed in vm_map_pageable_common():
if (entry->protection & access_type) != access_type, it returns
KERN_FAILURE.

A simple solution would be to change the implementation of mlock(): make
it call just vm_wire(blabla, VM_PROT_READ), which will work for both
code, data, and stack. Yes, it is sufficient for preventing the process
from copy-on-write faults too, because even if VM_PROT_WRITE is not
given, vm_map_pageable_common() will perform the copy. This solution
will however probably not work for pages that were mprotect(PROT_NONE)
-ed (i.e. entry->protection == 0, not even VM_PROT_READ).

Another solution would be to add an additionnal VM_PROT_LOCKED flag that
would exactly mean what mlock() needs: the page is resident and no copy
on write will happen. And then use only that one in glibc. It shouldn't
be very difficult to implement.

Regards,
Samuel