mirror of https://github.com/mkerrisk/man-pages
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>
This commit is contained in:
parent
46305699f7
commit
fb08a0954e
14
man2/mlock.2
14
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).
|
||||
|
|
Loading…
Reference in New Issue