Provided by: manpages-de-dev_4.23.1-1_all 
BEZEICHNUNG
mlock, mlock2, munlock, mlockall, munlockall - Speicher (ent)sperren
BIBLIOTHEK
Standard-C-Bibliothek (libc, -lc)
ÜBERSICHT
#include <sys/mman.h>
int mlock(const void Adresse[.len], size_t Länge);
int mlock2(const void Addresse[.len], size_t Länge, unsigned int Schalter);
int munlock(const void Adresse[.len], size_t Länge);
int mlockall(int Schalter);
int munlockall(void);
BESCHREIBUNG
mlock(), mlock2() und mlockall() sperrt den gesamten oder einen Teil des virtuellen
Adressraums des aufrufenden Prozesses im RAM und verhindern, dass der Speicherinhalt in
den Auslagerungsbereich ausgelagert wird.
munlock() und munlockall() führen die umgekehrte Aktion durch, d.h. entsperren 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.
(Ent)sperren des Speichers wird für ganze Speicherseiten durchgeführt.
mlock(), mlock2() und munlock()
mlock() sperrt Seiten im Adressbereich, der bei adr beginnt und sich über Länge 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 entsperrt werden.
mlock2() sperrt auch Seiten im Adressbereich, der bei adr beginnt und sich über Länge Byte
erstreckt. Der Status der Seiten, die in dem angegebenen Adressbereichs nach einem
erfolgreichen Aufruf enthalten sind, hängt vom Wert des Schalter-Arguments ab.
Das Argument Schalter kann entweder 0 oder die folgende Konstante sein:
MLOCK_ONFAULT
Sperrt Seiten, die derzeit im Speicher sind, und markiert den gesamten Bereich, so
dass die verbleibenden, nicht im Speicher befindlichen Seiten gesperrt sind, wenn
Sie durch eine Seitenausnahmebehandlung befüllt werden.
Wenn flags 0 ist, verhält sich mlock2() genau so wie mlock().
munlock() entsperrt Seiten im Adressbereich, der mit adr beginnt und sich über Länge Byte
erstreckt. Nach diesem Aufruf können alle Seiten, die einen Teil des angegebenen
Speicherbereichs umfassen, erneut vom Kernel in externen Auslagerungsspeicher ausgelagert
werden.
mlockall() und munlockall()
mlockall() sperrt alle Seiten, die in den Adressraum des aufrufenden Prozesses gemappt
sind. Dieses bezieht sich auf die Seiten von Code-, Daten- und Stacksegment genauso wie
auf dynamische Bibliotheken, Kernel-Daten im Anwendungsraum, Gemeinsamen Speicher und in
den Speicher gemappte Dateien. Es wird garantiert, dass alle gemappten Speicherseiten im
RAM sind, wenn der Aufruf von mlockall() erfolgreich beendet wird. Es wird darüber hinaus
garantiert, dass die Seiten solange im RAM bleiben, bis sie wieder entsperrt werden.
Das Argument Schalter wird mittels logischem bitweisem ODER aus einer oder mehreren der
folgenden Konstanten konstruiert:
MCL_CURRENT
sperrt alle Seiten, die momentan in den Adressraum des Prozesses gemappt sind.
MCL_FUTURE
sperrt alle Seiten, die in Zukunft in den Adressraum des Prozesses gemappt 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 gemappt werden, oder
gemeinsam benutzte Speicherbereiche.
MCL_ONFAULT (seit Linux 4.4)
Wird zusammen mit MCL_CURRENT, MCL_FUTURE oder beiden verwandt. Markiert alle
aktuellen (mit MCL_CURRENT) oder zukünftigen (mit MCL_FUTURE) Mappings, dass sie
Seiten sperren, wenn diese durch Ausnahmebehandlungen hereingekommen sind. Bei der
Verwendung mit MCL_CURRENT, werden alle vorhandenen Seiten gesperrt, aber
mlockall() wird keine nicht vorhandenen Seiten durch Ausnahmebehandlungen
hereinbringen. Bei der Verwendung mit MCL_FUTURE werden alle zukünftigen Mappings
markiert, dass sie Seiten sperren, wenn diese durch Ausnahmebehandlungen
hereinkommen, sie werden aber durch die Sperre nicht befüllt, wenn das Mapping
erstellt wird. MCL_ONFAULT muss entweder mit MCL_CURRENT, MCL_FUTURE oder beiden
verwandt werden.
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 die Stack-Vergrößerung
verweigern und dem Prozess ein SIGSEGV-Signal schicken.
munlockall() entsperrt alle in den Addressraum des aufrufenden Prozesses gemappten Seiten.
RÜCKGABEWERT
Bei Erfolg geben diese Systemaufrufe 0 zurück. Bei einem Fehler wird -1 zurückgegeben,
errno gesetzt, um den Fehler anzuzeigen und keine Änderungen an den Sperren im Adressraum
des Prozesses durchgeführt.
FEHLER
EAGAIN (mlock(), mlock2() und munlock()) Ein Teil des angegebenen Adressbereichs oder der
gesamte Adressbereich konnten nicht gesperrt werden.
EINVAL (mlock(), mlock2() und munlock()) Das Ergebnis der Addition adr+Länge war kleiner
als adr (z. B. kann die Addition einen Überlauf verursacht haben).
EINVAL (mlock2()) Es wurden unbekannte Schalter angegeben.
EINVAL (mlockall()) Es wurden entweder unbekannte Schalter angegeben oder MCL_ONFAULT
wurde weder mit MCL_FUTURE noch mit MCL_CURRENT angegeben.
EINVAL (Nicht unter Linux) addr war kein Vielfaches der Seitengröße.
ENOMEM (mlock(), mlock2() und munlock()) Ein Teil des angegebenen Adressbereichs
entspricht nicht Seiten, die in den Adressraum des Prozesses gemappt sind.
ENOMEM (mlock(), mlock2() und munlock()) Sperren oder Entsperren eines Bereiches würde
dazu führen, dass die Gesamtanzahl der Mappings mit eindeutigen Attributen (z.B.
gesperrt oder nicht gesperrt) das erlaubte Maximum überschreiten würde.
(Beispielsweise würde das Entsperren eines Bereichs in der Mitte eines derzeit
gesperrten Bereichs zu drei Mappings führen: zwei gesperrte Mappings an jedem Ende
und ein entsperrtes Mapping in der Mitte.)
ENOMEM (Linux 2.6.9 und neuer) Der Aufrufende hatte eine weiche Ressourcenbegrenzung
RLIMIT_MEMLOCK ungleich null, versuchte aber über diese Grenze hinaus Speicher zu
sperren. Diese Grenze wird nicht erzwungen, wenn der Prozess privilegiert ist
(CAP_IPC_LOCK).
ENOMEM (Linux 2.4 und älter) Der aufrufende Prozess versuchte, mehr als die Hälfte des
RAMs zu sperren.
EPERM Der Aufrufende ist nicht privilegiert, benötigt aber zur Durchführung der
angeforderten Aktionen Privilegien (CAP_IPC_LOCK).
EPERM (munlockall()) (Linux 2.6.8 und älter) Der Aufrufende war nicht privilegiert
(CAP_IPC_LOCK).
VERSIONEN
Linux
Unter Linux runden mlock(), mlock2() und munlock() adr automatisch zur nächsten
Seitengrenze ab. Da aber die POSIX.1-Spezifikation von mlock() und munlock()
Implementierungen gestattet, welche die Ausrichtung von adr an Seitengrenzen fordern,
sollten portable Anwendungen die Ausrichtung sicherstellen.
Das Feld VmLck der Linux-spezifischen Datei /proc/PID/status gibt an, wie viele Kilobyte
Speicher der Prozess mit der Kennung PID mittels mlock(), mlock2(), mlockall() und mmap(2)
mit dem Schalter MAP_LOCKED gesperrt hat.
STANDARDS
mlock()
munlock()
mlockall()
munlockall()
POSIX.1-2008.
mlock2()
Linux.
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).)
GESCHICHTE
mlock()
munlock()
mlockall()
munlockall()
POSIX.1-2001, POSIX.1-2008, SVr4.
mlock2()
Linux 4.4, Glibc 2.27.
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 Auslagerungsspeichermedium ü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 mlockall() Verzögerungen durch Seitenausnahmebehandlungen
vermeiden, sollten ausreichend gesperrte Stackseiten reservieren, bevor sie in die
zeitkritische Phase treten, sodass durch einen Funktionsaufruf keine
Seitenausnahmebehandlung 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 gemappt und können im RAM gesperrt werden.
Der Schreibvorgang stellt sicher, dass nicht einmal ein
Schreib-Kopier-Seitenausnahmebehandlung in der kritischen Phase eintreten kann.
Speichersperren werden nicht an mittels fork(2) erzeugte Kindprozesse vererbt und durch
einen Aufruf von execve(2) oder das Ende des Prozesses automatisch entfernt (entsperrt).
Die Einstellungen MCL_FUTURE und MCL_FUTURE | MCL_ONFAULT in mlockall() werden nicht von
einem Kindprozess ererbt, der mittels fork(2) erzeugt wurde und werden während eines
execve(2) gelöscht.
Beachten Sie, dass fork(2) den Adressraum für eine Kopieren-beim-Schreiben-Aktion
vorbereiten wird. Die Konsequenz ist, dass nachfolgende Schreibaktionen zu einer
Seitenausnahmebehandlung führen werden, die wiederum hohe Latenzen für Echtzeitprozesse
hervorrufen. Daher ist es essenziell, fork(2) nicht nach einer mlockall()- oder
mlock()-Aktion auszuführen - selbst nicht aus einem Thread, der bei niedriger Priorität
innerhalb eines Prozesses läuft, der wiederum einen Thread hat, der mit erhöhter Priorität
läuft.
Die Speichersperrung wird automatisch entfernt, wenn der Adressbereich mittels munmap(2)
entmappt wird.
Speichersperren werden nicht hochgezählt (»gestapelt«), das heißt, Seiten die mehrmals
durch den Aufruf von mlockall(), mlock2() oder mlock() gesperrt wurden werden durch einen
einzigen Aufruf von munlock() für den entsprechenden Bereich oder durch munlockall()
sofort wieder freigegeben. Seiten, die an verschiedene Orte oder für verschiedene Prozesse
gemappt wurden, bleiben solange im RAM gesperrt, wie sie mindestens an einem Ort oder
durch einen Prozess gesperrt sind.
Wenn einem Aufruf von mlockall(), der den Schalter MCL_FUTURE nutzt, ein weiterer Aufruf
folgt, der diesen Schalter nicht angibt, gehen die durch den Aufruf von MCL_FUTURE
erwirkten Änderungen verloren.
Der Schalter MLOCK_ONFAULT von mlock2() und der Schalter MCL_ONFAULT von mlockall()
erlaubt effizientes Speicher-Sperren für Anwendungen, die mit großen Mappings umgehen, bei
denen nur ein (kleiner) Anteil von Seiten im Mapping berührt werden. In diesen Fällen
würde das Sperren aller Seiten in dem Mapping eine erhebliche Einbuße für das
Speicher-Sperren verursachen.
Grenzen und Zugriffsrechte
Bis einschließlich Linux 2.6.8 muss ein Prozess privilegiert sein (CAP_IPC_LOCK), um
Speicher zu sperren. Die weiche Systembegrenzung RLIMIT_MEMLOCK bestimmt einen
Speicher-Schwellwert, den der Prozess sperren darf.
Seit Linux 2.6.9 kann ein privilegierter Prozess unbegrenzt Speicher sperren. Die weiche
Systembegrenzung RLIMIT_MEMLOCK legt stattdessen fest, wieviel Speicher ein nicht
privilegierter Prozess sperren darf.
FEHLER
In Linux 4.8 und älter bedeutete ein Fehler in der Bilanzierung des Kernels für gesperrten
Speicher von unprivilegierten Prozessen (d.h. solchen ohne CAP_IPC_LOCK), das die
gesperrten Bytes, die einer überlappenden (falls vorhanden) und durch adr und Länge
festgelegte Region liegen, beim Prüfen gegen die Begrenzung doppelt zählten. Solche
Doppelbilanzierung konnte zu einem inkorrekten Wert für den »total locked memory« für den
Prozess, der die Begrenzung RLIMIT_MEMLOCK überschritt, führen. Damit konnten dann mlock()
und mlock2() fehlschlagen, obwohl die Anfragen hätten erfolgreich sein sollen. Dieser
Fehler wurde in Linux 4.9 behoben.
In Linux 2.4.x bis einschließlich 2.4.17 bewirkte ein Fehler, dass der Schalter MCL_FUTURE
von mlockall() über einen Aufruf von fork(2) vererbt wurde. Dies wurde in Linux 2.4.18
behoben.
Seit Linux 2.6.9 werden, falls ein privilegierter Prozess mlockall(MCL_FUTURE) aufruft und
anschließend Privilegien aufgibt (die Capability CAP_IPC_LOCK verliert, weil er
beispielsweise seine effektive UID auf einen von null verschiedenen Wert setzt),
nachfolgende Speicherzuordnungen (z.B. mmap(2), brk(2)) fehlschlagen, wenn die
Ressourcengrenze RLIMIT_MEMLOCK angetroffen wird.
SIEHE AUCH
mincore(2), mmap(2), setrlimit(2), shmctl(2), sysconf(3), proc(5), capabilities(7)
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Hanno Wagner
<wagner@bidnix.bid.fh-hannover.de>, Martin Schulze <joey@infodrom.org>, Michaela Hohenner
<mhohenne@techfak.uni-bielefeld.de>, Martin Eberhard Schauer <Martin.E.Schauer@gmx.de>,
Mario Blättermann <mario.blaettermann@gmail.com> und Helge Kreutzmann
<debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.