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>

diff --git a/man2/mlock.2 b/man2/mlock.2
index e34bb3b4e045dda906e9503a6e8d0b2613ebaa7b..27f80f6664efc3a5527ff3bb2d29ed6c86ab445f 100644 (file)
--- 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).