From 083ddbc2c7f3379eafe59ac5a1bdb0b18049d416 Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Fri, 3 Feb 2006 20:56:21 +0000 Subject: [PATCH] Added BUGS txt on interaction between MCL_FUTURE and RLIMIT_MEMLOCK. See the following LKML thread: http://marc.theaimsgroup.com/?l=linux-kernel&m=113801392825023&w=2 "Rationale for RLIMIT_MEMLOCK" --- man2/mlock.2 | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/man2/mlock.2 b/man2/mlock.2 index 19b95fe82..3b303967b 100644 --- a/man2/mlock.2 +++ b/man2/mlock.2 @@ -24,7 +24,7 @@ .\" Software Foundation, Inc., 59 Temple Place, Suite 330, .\" Boston, MA 02111, USA. .\" -.TH MLOCK 2 2004-11-25 "Linux 2.6.9" "Linux Programmer's Manual" +.TH MLOCK 2 2005-02-04 "Linux 2.6.15" "Linux Programmer's Manual" .SH NAME mlock, munlock, mlockall, munlockall \- lock and unlock memory .SH SYNOPSIS @@ -269,6 +269,23 @@ a bug caused the flag to be inherited across a .BR fork (2). This was rectified in kernel 2.4.18. + +Since kernel 2.6.9, if a privileged process calls +.I mlockall(MCL_FUTURE) +and later drops privileges (loses the +.B CAP_IPC_LOCK +capability by, for example, +setting its effective UID to a non-zero value), +then subsequent memory allocations (e.g., +.BR mmap (2), +.BR brk (2)) +will fail if the +.B RLIMIT_MEMLOCK +resource limit is encountered. +.\" See the following LKML thread: +.\" http://marc.theaimsgroup.com/?l=linux-kernel&m=113801392825023&w=2 +.\" "Rationale for RLIMIT_MEMLOCK" +.\" 23 Jan 2006 .SH AVAILABILITY On POSIX systems on which .BR mlock ()