[Top][All Lists]

[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


It seems that the bug#15403[1] reply didn't get CCed to bug-hurd, so
here it is:


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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]