[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug #15403 : can't mlock mmap'd memory
From: |
Samuel Thibault |
Subject: |
bug #15403 : can't mlock mmap'd memory |
Date: |
Wed, 18 Jan 2006 01:47:44 +0100 |
User-agent: |
Mutt/1.5.9i-nntp |
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 #15403 : can't mlock mmap'd memory,
Samuel Thibault <=