Provided by: manpages-de-dev_1.4-1_all 
BEZEICHNUNG
mlock, munlock, mlockall, munlockall - Speicher ver- und entriegeln
ÜBERSICHT
#include <sys/mman.h>
int mlock(const void *addr, size_t len);
int munlock(const void *addr, size_t len);
int mlockall(int flags);
int munlockall(void);
BESCHREIBUNG
mlock() bzw. mlockall() bzw. verriegeln den gesamten oder einen Teil des virtuellen
Adressraums des aufrufenden Prozesses im RAM und verhindern, dass der Speicherinhalt in
den Swap-Bereich ausgelagert wird. munlock() und munlockall () führen die umgekehrte
Operation durch bzw. entriegeln den gesamten oder einen Teil des virtuellen Adressraums
des aufrufenden Prozesses, sodass die Seiten im angegebenen virtuellen Adressbereich
wieder ausgelagert werden können, wenn das von der Kernel-Speicherverwaltung verlangt
wird. Ver- und Entriegelung des Speichers werden für ganze Speicherseiten durchgeführt.
mlock() und munlock()
mlock() verriegelt Seiten im Adressbereich, der bei addr beginnt und sich über len Byte
erstreckt. Alle Seiten, die einen Teil des angegebenen Adressbereichs enthalten,
verbleiben nach einem erfolgreichen Aufruf garantiert im RAM; die Seiten bleiben
garantiert im RAM, bis sie wieder entriegelt werden.
munlock() entriegelt Seiten im Adressbereich, der mit addr beginnt und sich über len Byte
erstreckt. Nach diesem Aufruf können alle Seiten, die einen Teil des angegebenen
Speicherbereichs umfassen, erneut vom Kernel in externen Swap-Speicher ausgelagert werden.
mlockall() und munlockall()
mlockall() sperrt das Paging für alle Seiten, die in den Adressraum des aufrufenden
Prozesses eingebunden sind. Dieses bezieht sich auf die Seiten von Code-, Daten- und
Stacksegment genauso wie auf gemeinsame Bibliotheken, Kernel-Daten im Userspace, Shared
Memory und auf den Speicher abgebildete Dateien. Es wird garantiert, dass alle
eingebundenen Speicherseiten im RAM bleiben, wenn der Aufruf von mlockall() erfolgreich
beendet wird. Es wird darüber hinaus garantiert, dass die Seiten solange im RAM bleiben,
bis sie wieder entriegelt werden.
Das Argument flags wird mittels logischem ODER aus einer oder mehreren der folgenden
Konstanten konstruiert:
MCL_CURRENT sperrt alle Seiten, die momentan in den Adressraum des Prozesses eingeblendet
sind.
MCL_FUTURE sperrt alle Seiten, die in Zukunft in den Adressraum des Prozesses
eingeblendet werden. Das könnten zum Beispiel neue Adress-Seiten sein, die bei
einem sich vergrößernden Heap und Stack benötigt werden, Dateien, die in den
Speicher eingeblendet werden, oder gemeinsam benutzte Speicherbereiche.
Falls MCL_FUTURE angegeben wurde, kann ein späterer Systemaufruf (z. B. mmap(2), sbrk(2),
malloc (3)) fehlschlagen, wenn durch ihn die Zahl gesperrter Bytes das zulässige Maximum
überschreiten würde (siehe unten). Unter den gleichen Voraussetzungen kann eine
Vergrößerung des Stacks ebenfalls fehlschlagen: der Kernel wird den Stack-Ausbau
verweigern und dem Prozess ein SIGSEGV-Signal schicken.
munlockall() entriegelt alle in den Addressraum des aufrufenden Prozesses eingeblendeten
Seiten.
RÜCKGABEWERT
Bei Erfolg geben diese Systemaufrufe 0 zurück. Bei einem Fehler wird -1 zurückgegeben,
errno entsprechend gesetzt und keine Änderungen an den Sperren im Adressraum des Prozesses
durchgeführt.
FEHLER
ENOMEM (Linux 2.6.9 und später) Der Aufrufende hatte eine weiche Ressourcenbegrenzung
RLIMIT_MEMLOCK ungleich null, versuchte aber über diese Grenze hinaus Speicher zu
verriegeln. Diese Grenze wird nicht erzwungen, wenn der Prozess privilegiert ist
(CAP_IPC_LOCK).
ENOMEM (Linux 2.4 und früher) Der aufrufende Prozess versuchte mehr als die Hälfte des
RAMs zu verriegeln.
EPERM Der Aufrufende ist nicht privilegiert, benötigt aber zur Durchführung der
angeforderten Operation Privilegien (CAP_IPC_LOCK).
Für mlock() und munlock():
EAGAIN Ein Teil des angegebenen Adressbereichs oder der gesamte Adressbereich konnten
nicht verriegelt werden.
EINVAL Das Ergebnis der Addition start+len war kleiner als start (z. B. kann die Addition
einen Überlauf verursacht haben.)
EINVAL (Nicht unter Linux) addr war kein Vielfaches der Seitengröße.
ENOMEM Ein Teil des angegebenen Adressbereichs entspricht nicht Seiten, die in den
Adressraum des Prozesses eingeblendet sind.
Für mlockall():
EINVAL Es wurden unbekannte Flags angegeben.
Für munlockall():
EPERM (Linux 2.6.8 und früher) Der Aufrufende war nicht privilegiert (CAP_IPC_LOCK).
KONFORM ZU
POSIX.1-2001, SVr4.
VERFÜGBARKEIT
Auf POSIX-Systemen, auf denen mlock() und munlock() verfügbar sind, ist
_POSIX_MEMLOCK_RANGE in <unistd.h> definiert und die Anzahl der Bytes pro Seite kann der
Konstante PAGESIZE (wenn sie definiert ist) in <limits.h> entnommen werden oder durch
einen Aufruf von sysconf(_SC_PAGESIZE) bestimmt werden.
Auf POSIX-Systemen, auf denen mlockall() und munlockall() verfügbar sind, ist
_POSIX_MEMLOCK in <unistd.h> als ein Wert größer als 0 definiert. (Siehe auch sysconf(3).)
ANMERKUNGEN
Das Sperren von Speicher hat zwei Hauptanwendungen: Echtzeitalgorithmen und
Hochsicherheits-Datenverarbeitung. Echtzeitanwendungen erfordern deterministisches Timing,
und, wie auch Scheduling, ist Paging einer der Hauptgründe für unerwartete Verzögerungen
in der Programmausführung. Echtzeitanwendungen werden außerdem für gewöhnlich mit
sched_setscheduler(2) auf einen Echtzeit-Scheduler umschalten. Kryptographische
Sicherheitssoftware stellt oft sicherheitskritische Bytes wie Passwörter oder geheime
Schlüssel als Datenstrukturen dar. Durch Paging könnten diese geheimen Daten auf ein
permanentes Swap-Speichermedium übertragen werden, von wo aus sie auch dann noch Dritten
zugänglich sein können, lange nachdem das Programm die geheimen Daten aus dem RAM gelöscht
und sich beendet hat. (Bedenken Sie bitte, dass der Suspend-Modus von Laptops und manchen
Desktop-Rechnern, unabhängig von Speichersperren, eine Kopie des RAMs auf der Platte
speichern wird.)
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 memory
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 process 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 several times by calls to
mlock() or mlockall() will be unlocked by a single 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 location
or by at least one process.
Linux-Anmerkungen
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.
The VmLck field of the Linux-specific /proc/PID/status file shows how many kilobytes of
memory the process with ID PID has locked using mlock(), mlockall(), and mmap(2)
MAP_LOCKED.
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.
Seit Linux 2.6.9 kann ein privilegierter Prozess unbegrenzt Speicher verriegeln. Die
weiche Systembegrenzung RLIMIT_MEMLOCK legt stattdessen fest, wieviel Speicher ein nicht
privilegierter Prozess verriegeln darf.
FEHLER
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 nonzero value), then subsequent memory allocations (e.g., mmap(2), brk(2)) will fail
if the RLIMIT_MEMLOCK resource limit is encountered.
SIEHE AUCH
mmap(2), setrlimit(2), shmctl(2), sysconf(3), proc(5), capabilities(7)
KOLOPHON
This page is part of release 3.54 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/.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Michaela Hohenner
<mhohenne@techfak.uni-bielefeld.de>, Hanno Wagner <wagner@bidnix.bid.fh-hannover.de>,
Martin Schulze <joey@infodrom.org> und Martin Eberhard Schauer <Martin.E.Schauer@gmx.de>
erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG
übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
Mail an <debian-l10n-german@lists.debian.org>.