mlock.2: Document that fork() after mlock() may be a bad idea in a RT process

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>