mlockのヘルプ・マニュアル
日本語 英語
mlock --help
man mlock
MLOCK(2) Linux Programmer’s Manual MLOCK(2)
名前
mlock - メモリのロックとロック解除を行う
書式
#include
int mlock(const void *addr, size_t len);
int munlock(const void *addr, size_t len);
int mlockall(int flags);
int munlockall(void);
説明
mlock() と mlockall() はそれぞれ、呼び出し元プロセスの仮想アドレス空間
の一部または全部を RAM 上にロックし、メモリがスワップエリアにページング
されるのを防ぐ。 munlock() と munlockall() は逆の操作で、それぞれ呼び出
し元プロセスの仮想アドレス空間の一部または全部をロック解除する。つま り
、 指定された仮想アドレス範囲のページはカーネルメモリマネージャーから要
求されればスワップアウトするようになる。メモリのロックとロック解除は ペ
ージ単位で行われる。
mlock() と munlock()
mlock() は addr から始まる長さ len バイトのアドレス範囲のページをロック
する。呼び出しが成功した場合には、指定されたアドレス範囲を含む全ての ペ
ージは RAM に残り続けることが保証される。これらのページは後でロック解除
されるまで RAM に残り続けることが保証される。
munlock() は、 addr から始まる長さ len バイトのアドレス範囲のページのロ
ッ クを解除する。この呼び出しを行った後は、カーネルが、指定されたメモリ
範囲を含む全てのページを外部のスワップ空間に移動できるようになる。
mlockall() と munlockall()
mlockall() は呼び出し元プロセスのアドレス空間にマップされている全てのペ
ー ジをロックする。これにはコード、データ、スタックの各セグメント、共有
ライブラリ、カーネルのユーザー空間データ、共有メモリ、メモリ・マップ さ
れ たファイルが含まれる。システム・コールが成功した場合には全てのマップ
されたページは RAM に残ることを保証される。これらのページは後でロック解
除されるまで RAM に残り続けることが保証される。
flags 引数は以下の内容の一つまたは複数のビット OR から構成される:
MCL_CURRENT 現在、プロセスのアドレス空間にマップされている全てのページ
をロックする。
MCL_FUTURE 将来、プロセスのアドレス空間にマップされる全てのページを ロ
ッ クする。例えば、ヒープ (heap) やスタックの成長により新し
く必要になったページだけでなく、新しくメモリマップされた フ
ァイルや共有メモリ領域もロックされる。
MCL_FUTURE が指定されていると、以後のシステムコール (例えば、 mmap(2),
sbrk(2), malloc(3)) は、ロックするバイト数が許可された最大値 (下記参照)
を 超えた場合に失敗する可能性がある。同様に、スタックの成長も失敗する可
能性がある。その場合、カーネルはスタックの拡張を拒否し、 SIGSEGV をプロ
セスに送る。
munlockall() は、呼び出し元プロセスのアドレス空間にマッピングされている
全てのページをロック解除する。
返り値
成功した場合は、これらのシステムコールはゼロを返す。エラーの場合 は -1
が返され、 errno が適切に設定され、プロセスのアドレス空間におけるロック
は変更されない。
エラー
ENOMEM (Linux 2.6.9 以降) 呼び出し元は 非 ゼ ロ の ソ フ ト 資 源 制 限
RLIMIT_MEMLOCK を持つが、制限が許可している以上のメモリをロック
しようとした。この制限は、プロセスが特権 (CAP_IPC_LOCK) を持って
いる場合は適用されない。
ENOMEM (Linux 2.4 以前) 呼び出し元プロセスが RAM の半分以上をロックしよ
うとした。
EPERM (Linux 2.6.9 以降) 呼び出し元は特権 (CAP_IPC_LOCK) を持たず、 ソ
フト資源制限 RLIMIT_MEMLOCK が 0 である。
EPERM (Linux 2.6.8 以前) 呼び出し元プロセスが munlockall() を呼び出す
のに必要な特権を所有していなかった。 Linux では 、 CAP_IPC_LOCK
ケーパビリティが必要である。
mlock() と munlock() 用として:
EAGAIN 指定されたアドレス範囲の一部または全てをロックすることができなか
った。
EINVAL len が負の数である。
EINVAL (Linux ではこの意味で使われない) addr がページサイズの倍数ではな
い。
ENOMEM 指定されたアドレス範囲がプロセスのアドレス空間にマップされたペー
ジと一致しない。
mlockall() 用として:
EINVAL 未知の flags が指定された。
munlockall() 用として:
EPERM (Linux 2.6.8 以前) 呼び出し元が権限 (CAP_IPC_LOCK) を持ってい な
い。
準拠
POSIX.1-2001, SVr4.
可用性
mlock() と munlock() が 使 用可能な POSIX システムでは _POSIX_MEM-
LOCK_RANGE が で定義されている。また、ページあたりのバイト数
は、 で定義される定数 PAGESIZE から (定義されている場合)、も
しくは sysconf(_SC_PAGESIZE) を呼び出すことで決定できる。
mlockall() と munlockall() が利用可 能 な POSIX シ ス テ ム で は 、
_POSIX_MEMLOCK は で 0 よ り大きい値に定義されている
(sysconf(3) も参照のこと)。
注意
メモリのロックの用途としては主に二つある: リアルタイムアルゴリズムと 高
い セキュリティの必要なデータ処理である。リアルタイムのアプリケーション
は決定的なタイミングやスケジューリングを必要とするが、ページングは予 期
し ないプログラムの実行遅延をもたらす主要な要因となる。リアルタイムのア
プリケーションはたいていは sched_setscheduler(2) でリアルタイムスケジュ
ー ラに変更される。暗号やセキュリティのソフトウェアはしばしばパスワード
や秘密鍵のデータのような重要なバイト列を扱う。ページングの結果、これ ら
の 秘密がスワップ用の固定媒体に転送されるかもしれない。そして、セキュリ
ティ・ソフトウェアが RAM 上の秘密を削除して終了したずっと後になっても、
こ のスワップされたデータには敵がアクセスできる可能性がある (しかし、ラ
ップトップといくつかのデスクトップコンピュータのサスペンドモードはシ ス
テ ム の RAM の内容をメモリのロックに関わらずディスクに保存することに注
意)。
リアルタイムプロセスが mlockall() を使ってページフォールトによる遅延 を
防 ごうとする場合、関数呼び出しによってページフォールトが発生しないよう
に、時間制限の厳しい部分 (time-critical section) に入る前に十分な量のロ
ッ クされたスタックを確保しておく必要がある。これを実現するには、十分な
大きさの自動変数 (の配列) を確保し、これらのスタック用のページがメモ リ
上 に確保されるようにこの配列に書き込みを行う関数を用意し、これを呼び出
せばよい。こうすることで、十分な量のページがスタックにマッピン グ さ れ
、RAM にロックされる。ダミーの書き込みを行うことによって、時間制限の厳
しい部分 (critical section) 内では書き込み時コピーによるページフォー ル
トさえも発生しないことが保証される。
メモリロックは fork(2) で作成された子プロセスには継承されず、 execve(2)
が呼ばれたり、プロセスが終了した場合は自動的に削除される (ロック解除 さ
れる)。
あるアドレス範囲に対するメモリロックは、そのアドレス範囲が munmap(2) に
よってアンマップされた場合は削除される。
メモリのロックは累積しない。すなわち複数回 mlock() や mlockall() を呼び
出 してロックされたページでも、対応する範囲に対して munlock() を 1 回呼
び出したり munlockall() を呼び出したりするだけでロック解除される。複 数
の 場所や複数のプロセスにマップされているページは、少なくとも一つの場所
、一つのプロセスでロックされている限りは RAM に残り続ける。
Linux での注意
Linux では、 mlock() と munlock() は自動的に addr を端数切り捨てによ り
一 番近いページ境界へと丸める。しかし POSIX.1-2001 は addr がページ境界
に合っていることを要求する実装も許している。そのため移植性を意図した ア
プリケーションではきちんと境界に合わせた方が良い。
制限と権限
Linux 2.6.8 以前では、メモリをロックするためには特権 (CAP_IPC_LOCK) が
必要で、ソフト資源制限 RLIMIT_MEMLOCK はプロセスがどれだけのメモリを ロ
ックできるかの制限を定義する。
Linux 2.6.9 以降では、特権を持つプロセスがロックできるメモリ量は無制限
となり、代わりにソフト資源制限 RLIMIT_MEMLOCK は特権を持たないプロセ ス
がロックできるメモリ量の制限を定義する。
バグ
2.4.17 までの 2.4 シリーズの Linux カーネルには、 mlockall() MCL_FUTURE
フラグが fork(2) で継承されると言うバグがある。これはカーネル 2.4.18 で
修正された。
カーネル 2.6.9 以降では、特権を持ったプロセスが mlockall(MCL_FUTURE) を
呼び出した後で、特権をなくした場合 (例えば、実効 UID を 0 以外の値に 変
更するなどにより、 CAP_IPC_LOCK ケーパビリティを失った場合)、リソース上
限 RLIMIT_MEMLOCK に達すると、それ以降のメモリ割り当て (例えば mmap(2),
brk(2)) は失敗する。
関連項目
mmap(2), setrlimit(2), shmctl(2), sysconf(3), capabilities(7)
Linux 2008-09-25 MLOCK(2)
MLOCK(2) Linux Programmer’s Manual MLOCK(2)
NAME
mlock, munlock, mlockall, munlockall - lock and unlock memory
SYNOPSIS
#include
int mlock(const void *addr, size_t len);
int munlock(const void *addr, size_t len);
int mlockall(int flags);
int munlockall(void);
DESCRIPTION
mlock() and mlockall() respectively lock part or all of the calling
process’s virtual address space into RAM, preventing that memory from
being paged to the swap area. munlock() and munlockall() perform the
converse operation, respectively unlocking part or all of the calling
process’s virtual address space, so that pages in the specified virtual
address range may once more to be swapped out if required by the kernel
memory manager. Memory locking and unlocking are performed in units of
whole pages.
mlock() and munlock()
mlock() locks pages in the address range starting at addr and continu-
ing for len bytes. All pages that contain a part of the specified
address range are guaranteed to be resident in RAM when the call
returns successfully; the pages are guaranteed to stay in RAM until
later unlocked.
munlock() unlocks pages in the address range starting at addr and con-
tinuing for len bytes. After this call, all pages that contain a part
of the specified memory range can be moved to external swap space again
by the kernel.
mlockall() and munlockall()
mlockall() locks 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 call returns successfully; the pages are guaranteed to
stay in RAM until later unlocked.
The flags argument is constructed as the bitwise OR of one or more 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, then a later system call (e.g.,
mmap(2), sbrk(2), malloc(3)), may fail if it would cause the number of
locked bytes to exceed the permitted maximum (see below). In the same
circumstances, stack growth may likewise fail: the kernel will deny
stack expansion and deliver a SIGSEGV signal to the process.
munlockall() unlocks all pages mapped into the address space of the
calling process.
RETURN VALUE
On success these system calls return 0. On error, -1 is returned,
errno is set appropriately, and no changes are made to any locks in the
address space of the process.
ERRORS
ENOMEM (Linux 2.6.9 and later) the caller had a non-zero RLIMIT_MEMLOCK
soft resource limit, but tried to lock more memory than the
limit permitted. This limit is not enforced if the process is
privileged (CAP_IPC_LOCK).
ENOMEM (Linux 2.4 and earlier) the calling process tried to lock more
than half of RAM.
EPERM (Linux 2.6.9 and later) the caller was not privileged
(CAP_IPC_LOCK) and its RLIMIT_MEMLOCK soft resource limit was 0.
EPERM (Linux 2.6.8 and earlier) The calling process has insufficient
privilege to call munlockall(). Under Linux the CAP_IPC_LOCK
capability is required.
For mlock() and munlock():
EAGAIN Some or all of the specified address range could not be locked.
EINVAL len was negative.
EINVAL (Not on Linux) addr was not a multiple of the page size.
ENOMEM Some of the specified address range does not correspond to
mapped pages in the address space of the process.
For mlockall():
EINVAL Unknown flags were specified.
For munlockall():
EPERM (Linux 2.6.8 and earlier) The caller was not privileged
(CAP_IPC_LOCK).
CONFORMING TO
POSIX.1-2001, SVr4.
AVAILABILITY
On POSIX systems on which mlock() and munlock() are available,
_POSIX_MEMLOCK_RANGE is defined in and the number of bytes
in a page can be determined from the constant PAGESIZE (if defined) in
or by calling sysconf(_SC_PAGESIZE).
On POSIX systems on which mlockall() and munlockall() are available,
_POSIX_MEMLOCK is defined in to a value greater than 0.
(See also sysconf(3).)
NOTES
Memory locking has two main applications: real-time algorithms and
high-security data processing. Real-time applications require deter-
ministic timing, and, like scheduling, paging is one major cause of
unexpected program execution delays. Real-time applications will usu-
ally also switch to a real-time scheduler with sched_setscheduler(2).
Cryptographic security software often handles critical bytes like pass-
words or secret keys as data structures. As a result of paging, these
secrets could be transferred 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. (But be aware that the
suspend mode on laptops and some desktop computers will save a copy of
the system’s RAM to disk, regardless of memory locks.)
Real-time processes that are using mlockall() to prevent delays on page
faults 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 that allocates a
sufficiently large automatic variable (an array) and writes to the mem-
ory occupied by this 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 are not inherited by a child created via fork(2) and are
automatically removed (unlocked) during an execve(2) or when the pro-
cess terminates.
The memory lock on an address range is automatically removed if the
address range is unmapped via munmap(2).
Memory locks do not stack, that is, pages which have been locked sev-
eral times by calls to mlock() or mlockall() will be unlocked by a sin-
gle call to munlock() for the corresponding range or by 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 loca-
tion or by at least one process.
Linux Notes
Under Linux, mlock() and munlock() automatically round addr down to the
nearest page boundary. However, POSIX.1-2001 allows an implementation
to require that addr is page aligned, so portable applications should
ensure this.
Limits and permissions
In Linux 2.6.8 and earlier, a process must be privileged (CAP_IPC_LOCK)
in order to lock memory and the RLIMIT_MEMLOCK soft resource limit
defines a limit on how much memory the process may lock.
Since Linux 2.6.9, no limits are placed on the amount of memory that a
privileged process can lock and the RLIMIT_MEMLOCK soft resource limit
instead defines a limit on how much memory an unprivileged process may
lock.
BUGS
In the 2.4 series Linux kernels up to and including 2.4.17, a bug
caused the mlockall() MCL_FUTURE flag to be inherited across a fork(2).
This was rectified in kernel 2.4.18.
Since kernel 2.6.9, if a privileged process calls mlockall(MCL_FUTURE)
and later drops privileges (loses the CAP_IPC_LOCK capability by, for
example, setting its effective UID to a non-zero value), then subse-
quent memory allocations (e.g., mmap(2), brk(2)) will fail if the
RLIMIT_MEMLOCK resource limit is encountered.
SEE ALSO
mmap(2), setrlimit(2), shmctl(2), sysconf(3), capabilities(7)
COLOPHON
This page is part of release 3.22 of the Linux man-pages project. A
description of the project, and information about reporting bugs, can
be found at http://www.kernel.org/doc/man-pages/.
Linux 2008-09-25 MLOCK(2)