From fb08a0954ecfde61ad671ce60ed22c358298fe28 Mon Sep 17 00:00:00 2001 From: Sebastian Andrzej Siewior Date: Tue, 30 Aug 2016 10:59:11 +0200 Subject: [PATCH] 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 --- man2/mlock.2 | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/man2/mlock.2 b/man2/mlock.2 index e34bb3b4e..27f80f666 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).