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"
This commit is contained in:
Michael Kerrisk 2006-02-03 20:56:21 +00:00
parent cbea10b39a
commit 083ddbc2c7
1 changed files with 18 additions and 1 deletions

View File

@ -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 ()