Differences between version 2 and previous revision of mlockall(2).
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 2 | Last edited on Monday, March 10, 2003 8:14:21 pm | by PerryLorier | Revert |
| Older page: | version 1 | Last edited on Tuesday, June 4, 2002 12:23:43 am | by perry | Revert |
@@ -1,143 +1,41 @@
-MLOCKALL
-!!!MLOCKALL
-NAME
-SYNOPSIS
-DESCRIPTION
-RETURN VALUE
-ERRORS
-CONFORMING TO
-SEE ALSO
-----
!!NAME
-
-
mlockall - disable paging for calling process
!!SYNOPSIS
+ #include <sys/mman.h>
+ __int mlockall(int __''flags''__);__
-__#include
-__ ''flags''__);
-__
!!DESCRIPTION
+mlockall(2) disables paging for all pages mapped into the address space of the calling process. This includes the pages of the code, data and stack segment, as well as shared libraries, user space kernel data, shared memory and memory mapped files. All mapped pages are guaranteed to be resident in RAM when the mlockall(2) system call returns successfully and they are guaranteed to stay in RAM until the pages are unlocked again by munlock(2) or munlockall(2) or until the process terminates or starts
+another program with __exec__. Child processes do not inherit page locks across a fork(2).
+Memory locking has two main applications: real-time algorithms and high-security data processing. Real-time applications require deterministic timing, and, like
+scheduling, paging is one major cause of unexpected program execution delays. Real-time applications will usually also s witch to a real-time scheduler with
+__sched_setscheduler__. Cryptographic security software often handles critical bytes like passwords or secret keys as data structures. As a result of paging, these secrets could be transfered onto a persistent swap store medium, where they might be accessible to the enemy long after the security software has erased the secrets in RAM and terminated. For security applications, only small parts of memory have to be locked, for which mlock(2) is available.
-__mlockall
__ disables paging for
all pages mapped into
-calling
process. This includes the
-pages of the code, data
and stack segment,
as well as shared
-libraries, user space kernel data, shared
memory and memory
-. All mapped pages are guaranteed to be resident
-in RAM when the __mlockall__ system call returns
-successfully and they are guaranteed to stay in RAM until
-the pages are unlocked again by __munlock__
or
-__munlockall__ or until the process terminates or starts
-another program with __exec__. Child processes do not
-inherit page locks across a __fork__
.
+The ''flags'' parameter can be constructed from the bitwise OR of the following constants:
+;
__MCL
_CURRENT
__: Lock
all pages which are currently
mapped into the address space of the process.
+;__MCL_FUTURE__: Lock all
pages which will become mapped into the address space
of the process in the future. These could be for instance new pages required by a growing heap
and stack as well as new
memory mapped files or shared memory regions
.
+If __MCL_FUTURE__ has been specified and the number of locked pages exceeds the upper limit of allowed locked pages, then the system call which caused the new mapping
+will fail with [ENOMEM]. If these new pages have been mapped by the the growing stack, then the kernel will deny stack expansion and send a [SIGSEGV].
-Memory locking has two main applications: real-time
-algorithms and high-security data processing.
Real-time
-applications require deterministic timing, and, like
-scheduling, paging is one major cause of unexpected program
-execution delays. Real-
time applications will usually also
-switch to a real
-time scheduler with
-__sched_setscheduler__. Cryptographic security software
-often handles
critical bytes like passwords or secret keys
-as data structures. As a result of paging
, these secrets
-could
be transfered onto
a persistent swap store medium,
-where they might be accessible
to the enemy long after the
-security software has erased the secrets
in RAM and
-terminated
. For security applications
, only small parts of
-memory have to
be locked, for which __mlock__ is
-available
.
+Real-time processes should reserve enough locked stack pages before entering the
time-critical section
, so that no page fault can
be caused by function calls. This can be achieved by calling
a function which has a sufficiently large automatic variable and which writes
to the memory occupied by this large array
in order to touch these stack pages
. This way
, enough pages will be mapped for the stack and can
be locked into RAM. The dummy writes ensure that not even copy-on-write page faults can occur in the critical section
.
+Memory locks do not stack, i.e., pages which have been locked several times by calls to mlockall(2) or mlock(2) will be unlocked by a single call to munlockall(2). Pages which are mapped to several locations or by several processes stay locked into RAM as long as they are locked at least at one location or by at least one process.
-The ''flags'' parameter can be constructed from the
-bitwise OR of the following constants:
+On POSIX systems on which mlockall and munlockall are available, ___POSIX_MEMLOCK__ is defined in <unistd.h>.
-
-__MCL_CURRENT__
-
-
-Lock all pages which are currently mapped into the address
-space of the process.
-
-
-__MCL_FUTURE__
-
-
-Lock all pages which will become mapped into the address
-space of the process in the future. These could be for
-instance new pages required by a growing heap and stack as
-well as new memory mapped files or shared memory
-regions.
-
-
-If __MCL_FUTURE__ has been specified and the number of
-locked pages exceeds the upper limit of allowed locked
-pages, then the system call which caused the new mapping
-will fail with __ENOMEM__. If these new pages have been
-mapped by the the growing stack, then the kernel will deny
-stack expansion and send a __SIGSEGV__.
-
-
-Real-time processes should reserve enough locked stack pages
-before entering the time-critical section, so that no page
-fault can be caused by function calls. This can be achieved
-by calling a function which has a sufficiently large
-automatic variable and which writes to the memory occupied
-by this large array in order to touch these stack pages.
-This way, enough pages will be mapped for the stack and can
-be locked into RAM. The dummy writes ensure that not even
-copy-on-write page faults can occur in the critical
-section.
-
-
-Memory locks do not stack, i.e., pages which have been
-locked several times by calls to __mlockall__ or
-__mlock__ will be unlocked by a single call to
-__munlockall__. Pages which are mapped to several
-locations or by several processes stay locked into RAM as
-long as they are locked at least at one location or by at
-least one process.
-
-
-On POSIX systems on which __mlockall__ and
-__munlockall__ are available, ___POSIX_MEMLOCK__ is
-defined in __
!!RETURN VALUE
+On success, __mlockall__ returns zero. On error, -1 is returned, ''errno'' is set appropriately.
-
-On success, __mlockall__ returns zero. On error, -1 is
-returned, ''errno'' is set appropriately.
!!ERRORS
+;[ENOMEM]: The process tried to exceed the maximum number of allowed locked pages.
+;[EPERM]: The calling process does not have appropriate privileges. Only root processes are allowed to lock pages.
+;[EINVAL]: Unknown flags were specified.
-
-__ENOMEM__
-
-
-The process tried to exceed the maximum number of allowed
-locked pages.
-
-
-__EPERM__
-
-
-The calling process does not have appropriate privileges.
-Only root processes are allowed to lock pages.
-
-
-__EINVAL__
-
-
-Unknown flags were specified.
!!CONFORMING TO
+POSIX.1b, SVr4. SVr4 documents an additional [EAGAIN] error code.
-
-POSIX.1b, SVr4. SVr4 documents an additional EAGAIN error
-code.
!!SEE ALSO
-
-
-
-
-----
+munlockall(2), mlock(2), munlock(2)
