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 _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
