[lkml]   [2006]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRationale for RLIMIT_MEMLOCK?

debugging an application problem that used to mlockall(...FUTURE) and
failed with a subsequent mmap(), I came across the manual page for
setrlimit (see below for the relevant excerpt). I have several questions
concerning the rationale:

1. What is the reason we're having special treatment
for the super-user here?

2. Why is it the opposite of what and earlier did?

3. Why is this inconsistent with all other RLIMIT_*?
Neither of which cares if a process is privileged or not.

4. Is the default hard limit of 32 kB initialized by the kernel or
by some script in SUSE 10.0? If it's the kernel: why is the limit so
low, and why isn't just the soft limit set?

The maximum number of bytes of memory that may be locked into
RAM. In effect this limit is rounded down to the nearest multi-
ple of the system page size. This limit affects mlock(2) and
mlockall(2) and the mmap(2) MAP_LOCKED operation. Since Linux
2.6.9 it also affects the shmctl(2) SHM_LOCK operation, where it
sets a maximum on the total bytes in shared memory segments (see
shmget(2)) that may be locked by the real user ID of the calling
process. The shmctl(2) SHM_LOCK locks are accounted for sepa-
rately from the per-process memory locks established by
mlock(2), mlockall(2), and mmap(2) MAP_LOCKED; a process can
lock bytes up to this limit in each of these two categories. In
Linux kernels before 2.6.9, this limit controlled the amount of
memory that could be locked by a privileged process. Since
Linux 2.6.9, no limits are placed on the amount of memory that a
privileged process may lock, and this limit instead governs the
amount of memory that an unprivileged process may lock. [...]"
(getrlimit(2), man-pages-2.07)

Matthias Andree
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-01-23 12:01    [W:0.255 / U:1.944 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site