diff options
| author | Sebastian Andrzej Siewior <bigeasy@linutronix.de> | 2016-08-30 10:59:11 +0200 |
|---|---|---|
| committer | Michael Kerrisk <mtk.manpages@gmail.com> | 2016-08-31 07:23:08 +1200 |
| commit | fb08a0954ecfde61ad671ce60ed22c358298fe28 (patch) | |
| tree | 557855f0717901129fb461562cc4605a988578d1 | |
| parent | 46305699f773f3500d8527f6987500db230aa022 (diff) | |
| download | man-pages-fb08a0954ecfde61ad671ce60ed22c358298fe28.tar.gz | |
mlock.2: Document that fork() after mlock() may be a bad idea in a RT process
fork() will remove the write PTE bit from the page table on each
VMA which will be copied via COW. As such, the memory is available
but marked read only in the page table and will fault on write
access. This renders the previous mlock() operation almost
useless because in a multithreaded application a realtime thread
may block on mmap_sem while a thread with low priority is holding
the mmap_sem (for instance because it is allocating memory which
needs to be mapped in).
There is actually nothing we can do to mitigate the outcome. We could
add a warning to the kernel for people that are not yet aware of the
updated documentation.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
| -rw-r--r-- | man2/mlock.2 | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/man2/mlock.2 b/man2/mlock.2 index e34bb3b4e0..27f80f6664 100644 --- a/man2/mlock.2 +++ b/man2/mlock.2 @@ -350,6 +350,20 @@ settings are not inherited by a child created via and are cleared during an .BR execve (2). +Note that +.BR fork (2) +will prepare the address space for a copy-on-write operation. The consequence +is that any write access that follows will cause a page fault which in turn may +cause high latencies for a real-time process. Therefore it is crucial not to +invoke +.BR fork (2) +after the +.BR mlockall () +or +.BR mlock () +operation not even from thread which runs at a low priority within a process +which also has a thread running at elevated priority. + The memory lock on an address range is automatically removed if the address range is unmapped via .BR munmap (2). |