.\" -*- coding: UTF-8 -*-
.\" Copyright (C) Michael Kerrisk, 2004
.\" using some material drawn from earlier man pages
.\" written by Thomas Kuhn, Copyright 1996
.\"
.\" %%%LICENSE_START(GPLv2+_DOC_FULL)
.\" This is free documentation; you can redistribute it and/or
.\" modify it under the terms of the GNU General Public License as
.\" published by the Free Software Foundation; either version 2 of
.\" the License, or (at your option) any later version.
.\"
.\" The GNU General Public License's references to "object code"
.\" and "executables" are to be interpreted as the output of any
.\" document formatting or typesetting system, including
.\" intermediate and printed output.
.\"
.\" This manual is distributed in the hope that it will be useful,
.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
.\" GNU General Public License for more details.
.\"
.\" You should have received a copy of the GNU General Public
.\" License along with this manual; if not, see
.\" .
.\" %%%LICENSE_END
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH MLOCK 2 "14. April 2014" Linux Linux\-Programmierhandbuch
.SH BEZEICHNUNG
mlock, munlock, mlockall, munlockall \- Speicher ver\- und entriegeln
.SH ÜBERSICHT
.nf
\fB#include \fP
.sp
\fBint mlock(const void *\fP\fIaddr\fP\fB, size_t \fP\fIlen\fP\fB);\fP
\fBint munlock(const void *\fP\fIaddr\fP\fB, size_t \fP\fIlen\fP\fB);\fP
.sp
\fBint mlockall(int \fP\fIflags\fP\fB);\fP
\fBint munlockall(void);\fP
.fi
.SH BESCHREIBUNG
\fBmlock\fP() bzw. \fBmlockall\fP() 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. \fBmunlock\fP()
und \fBmunlockall\fP () 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.
.SS "mlock() und munlock()"
\fBmlock\fP() verriegelt Seiten im Adressbereich, der bei \fIaddr\fP beginnt und
sich über \fIlen\fP 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.
\fBmunlock\fP() entriegelt Seiten im Adressbereich, der mit \fIaddr\fP beginnt und
sich über \fIlen\fP 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.
.SS "mlockall() und munlockall()"
\fBmlockall\fP() 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 \fBmlockall\fP() erfolgreich beendet wird. Es wird
darüber hinaus garantiert, dass die Seiten solange im RAM bleiben, bis sie
wieder entriegelt werden.
Das Argument \fIflags\fP wird mittels logischem ODER aus einer oder mehreren
der folgenden Konstanten konstruiert:
.TP 1.2i
\fBMCL_CURRENT\fP
sperrt alle Seiten, die momentan in den Adressraum des Prozesses
eingeblendet sind.
.TP
\fBMCL_FUTURE\fP
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.
.PP
Falls \fBMCL_FUTURE\fP angegeben wurde, kann ein späterer Systemaufruf (z.\ B. \fBmmap\fP(2), \fBsbrk\fP(2), \fBmalloc\fP (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 \fBSIGSEGV\fP\-Signal schicken.
\fBmunlockall\fP() entriegelt alle in den Addressraum des aufrufenden Prozesses
eingeblendeten Seiten.
.SH RÜCKGABEWERT
Bei Erfolg geben diese Systemaufrufe 0 zurück. Bei einem Fehler wird \-1
zurückgegeben, \fIerrno\fP entsprechend gesetzt und keine Änderungen an den
Sperren im Adressraum des Prozesses durchgeführt.
.SH FEHLER
.TP
\fBENOMEM\fP
(Linux 2.6.9 und später) Der Aufrufende hatte eine weiche
Ressourcenbegrenzung \fBRLIMIT_MEMLOCK\fP ungleich null, versuchte aber über
diese Grenze hinaus Speicher zu verriegeln. Diese Grenze wird nicht
erzwungen, wenn der Prozess privilegiert ist (\fBCAP_IPC_LOCK\fP).
.TP
\fBENOMEM\fP
.\" In the case of mlock(), this check is somewhat buggy: it doesn't
.\" take into account whether the to-be-locked range overlaps with
.\" already locked pages. Thus, suppose we allocate
.\" (num_physpages / 4 + 1) of memory, and lock those pages once using
.\" mlock(), and then lock the *same* page range a second time.
.\" In the case, the second mlock() call will fail, since the check
.\" calculates that the process is trying to lock (num_physpages / 2 + 2)
.\" pages, which of course is not true. (MTK, Nov 04, kernel 2.4.28)
(Linux 2.4 und früher) Der aufrufende Prozess versuchte mehr als die Hälfte
des RAMs zu verriegeln.
.TP
\fBEPERM\fP
.\"SVr4 documents an additional EAGAIN error code.
Der Aufrufende ist nicht privilegiert, benötigt aber zur Durchführung der
angeforderten Operation Privilegien (\fBCAP_IPC_LOCK\fP).
.LP
Für \fBmlock\fP() und \fBmunlock\fP():
.TP
\fBEAGAIN\fP
Ein Teil des angegebenen Adressbereichs oder der gesamte Adressbereich
konnten nicht verriegelt werden.
.TP
\fBEINVAL\fP
Das Ergebnis der Addition \fIstart\fP+\fIlen\fP war kleiner als \fIstart\fP (z.\ B. kann die Addition einen Überlauf verursacht haben.)
.TP
\fBEINVAL\fP
(Nicht unter Linux) \fIaddr\fP war kein Vielfaches der Seitengröße.
.TP
\fBENOMEM\fP
Ein Teil des angegebenen Adressbereichs entspricht nicht Seiten, die in den
Adressraum des Prozesses eingeblendet sind.
.LP
Für \fBmlockall\fP():
.TP
\fBEINVAL\fP
Es wurden unbekannte \fIFlags\fP angegeben.
.LP
Für \fBmunlockall\fP():
.TP
\fBEPERM\fP
(Linux 2.6.8 und früher) Der Aufrufende war nicht privilegiert
(\fBCAP_IPC_LOCK\fP).
.SH "KONFORM ZU"
POSIX.1\-2001, SVr4.
.SH VERFÜGBARKEIT
Auf POSIX\-Systemen, auf denen \fBmlock\fP() und \fBmunlock\fP() verfügbar sind,
ist \fB_POSIX_MEMLOCK_RANGE\fP in \fI\fP definiert und die
Anzahl der Bytes pro Seite kann der Konstante \fBPAGESIZE\fP (wenn sie
definiert ist) in \fI\fP entnommen werden oder durch einen
Aufruf von \fIsysconf(_SC_PAGESIZE)\fP bestimmt werden.
.\" POSIX.1-2001: It shall be defined to -1 or 0 or 200112L.
.\" -1: unavailable, 0: ask using sysconf().
.\" glibc defines it to 1.
Auf POSIX\-Systemen, auf denen \fBmlockall\fP() und \fBmunlockall\fP() verfügbar
sind, ist \fB_POSIX_MEMLOCK\fP in als ein Wert größer als 0
definiert. (Siehe auch \fBsysconf\fP(3).)
.SH 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
\fBsched_setscheduler\fP(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.)
Echtzeitprozesse, die mittels \fBmlockall\fP() Verzögerungen durch Page Faults
(Seitenfehler) vermeiden, sollten ausreichend gesperrte Stackseiten
reservieren, bevor sie in die zeitkritische Phase treten, sodass durch einen
Funktionsaufruf kein Fehler entstehen kann. Dies kann durch den Aufruf einer
Funktion erreicht werden, die eine ausreichend große automatische Variable
(ein Feld) erzeugt und in den Speicher schreibt, in dem die Variable liegt,
um diese Stackseiten zu belegen. Auf diesem Wege werden genug Seiten für den
Stack bereitgestellt und können im RAM verriegelt werden. Der Schreibvorgang
stellt sicher, dass nicht einmal ein Schreib\-Kopier\-Seitenfehler in der
kritischen Phase eintreten kann.
Speicherverriegelungen werden nicht an mittels \fBfork\fP(2) erzeugte
Kindprozesse vererbt und durch einen Aufruf von \fBexecve\fP(2) oder das Ende
des Prozesses automatisch entfernt (entriegelt). Die Einstellung
\fBMCL_FUTURE\fP in \fBmlockall\fP() wird nicht von einem Kindprozess ererbt, der
mittels \fBfork\fP(2) erzeugt wurde und wird während eines \fBexecve\fP(2)
gelöscht.
Die Speicherverriegelung wird automatisch entfernt, wenn der Adressbereich
mittels \fBmunmap\fP(2) ausgeblendet wird.
Speichersperren werden nicht hochgezählt (»gestapelt«), das heißt, Seiten
die mehrmals durch den Aufruf von \fBmlockall\fP() oder \fBmlock\fP() gesperrt
wurden werden durch einen einzigen Aufruf von \fBmunlock\fP() für den
entsprechenden Bereich oder durch \fBmunlockall\fP() sofort wieder
freigegeben. Seiten, die an verschiedene Orte oder für verschiedene Prozesse
eingeblendet wurden, bleiben solange im RAM verriegelt, wie sie mindestens
an einem Ort oder durch einen Prozess benötigt werden.
.SS Linux\-Anmerkungen
Unter Linux runden \fBmlock\fP() und \fBmunlock\fP() \fIaddr\fP automatisch zur
nächsten Seitengrenze ab. Da aber POSIX.1\-2001 Implementierungen gestattet,
welche die Ausrichtung von \fIaddr\fP an Seitengrenzen fordern, sollten
portable Anwendungen die Ausrichtung sicherstellen.
Das Feld \fIVmLck\fP der Linux\-spezifischen Datei \fI/proc/PID/status\fP gibt an,
wie viele Kilobytes Speicher der Prozess mit der ID \fIPID\fP mittels
\fBmlock\fP(), \fBmlockall\fP() und \fBmmap\fP(2) mit dem Flag \fBMAP_LOCKED\fP
verriegelt hat.
.SS "Grenzen und Zugriffsrechte"
Bis einschließlich Linux 2.6.8 muss ein Prozess privilegiert sein
(\fBCAP_IPC_LOCK\fP), um Speicher zu verriegeln. Die weiche Systembegrenzung
\fBRLIMIT_MEMLOCK\fP bestimmt einen Speicher\-Schwellwert, den der Prozess
verriegeln darf.
Seit Linux 2.6.9 kann ein privilegierter Prozess unbegrenzt Speicher
verriegeln. Die weiche Systembegrenzung \fBRLIMIT_MEMLOCK\fP legt stattdessen
fest, wieviel Speicher ein nicht privilegierter Prozess verriegeln darf.
.SH FEHLER
In den Linux\-Kerneln 2.4.x bis einschließlich 2.4.17 bewirkte ein Fehler,
dass das Flag \fBMCL_FUTURE\fP von \fBmlockall\fP() über einen Aufruf von
\fBfork\fP(2) vererbt wurde. Dies wurde in Kernel 2.4.18 behoben.
.\" See the following LKML thread:
.\" http://marc.theaimsgroup.com/?l=linux-kernel&m=113801392825023&w=2
.\" "Rationale for RLIMIT_MEMLOCK"
.\" 23 Jan 2006
Seit Kernel 2.6.9 werden, falls ein privilegierter Prozess
\fImlockall(MCL_FUTURE)\fP aufruft und anschließend Privilegien aufgibt (die
Capability \fBCAP_IPC_LOCK\fP verliert, weil er beispielsweise seine effektive
UID auf einen von null verschiedenen Wert setzt), nachfolgende
Speicherzuordnungen (z.B. \fBmmap\fP(2), \fBbrk\fP(2)) fehlschlagen, wenn die
Ressourcengrenze \fBRLIMIT_MEMLOCK\fP berührt wird.
.SH "SIEHE AUCH"
\fBmmap\fP(2), \fBsetrlimit\fP(2), \fBshmctl\fP(2), \fBsysconf\fP(3), \fBproc\fP(5),
\fBcapabilities\fP(7)
.SH KOLOPHON
Diese Seite ist Teil der Veröffentlichung 3.74 des Projekts
Linux\-\fIman\-pages\fP. Eine Beschreibung des Projekts, Informationen, wie
Fehler gemeldet werden können sowie die aktuelle Version dieser Seite finden
sich unter \%http://www.kernel.org/doc/man\-pages/.
.SH ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von
Michaela Hohenner ,
Hanno Wagner ,
Martin Schulze ,
Martin Eberhard Schauer
und
Mario Blättermann
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 .