Hello Sebastian On 08/30/2016 08:59 PM, Sebastian Andrzej Siewior wrote: > fork() will remove the write PTE bit from the page table on each VMA > which will be copied via COW. A such 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 > multi threaded application the RT thread may block on mmap_sem while the > 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@xxxxxxxxxxxxx> Thanks! Patch applied. Cheers, Michael > --- > man2/mlock.2 | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/man2/mlock.2 b/man2/mlock.2 > index e34bb3b4e045..27f80f6664ef 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). > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
