.\" -*- 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 "2. Februar 2018" Linux Linux\-Programmierhandbuch
.SH BEZEICHNUNG
mlock, mlock2, munlock, mlockall, munlockall \- Speicher (ent)sperren
.SH ÜBERSICHT
.nf
\fB#include \fP
.PP
\fBint mlock(const void *\fP\fIadr\fP\fB, size_t \fP\fILänge\fP\fB);\fP
\fBint mlock2(const void *\fP\fIadr\fP\fB, size_t \fP\fILänge\fP\fB, int \fP\fISchalter\fP\fB);\fP
\fBint munlock(const void *\fP\fIadr\fP\fB, size_t \fP\fILänge\fP\fB);\fP
.PP
\fBint mlockall(int \fP\fISchalter\fP\fB);\fP
\fBint munlockall(void);\fP
.fi
.SH BESCHREIBUNG
\fBmlock\fP(), \fBmlock2\fP() und \fBmlockall\fP() sperrt den gesamten oder einen
Teil des virtuellen Adressraums des aufrufenden Prozesses im RAM und
verhindern, dass der Speicherinhalt in den Auslagerungsbereich ausgelagert
wird.
.PP
\fBmunlock\fP() und \fBmunlockall\fP() 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.
.PP
(Ent)sperren des Speichers wird für ganze Speicherseiten durchgeführt.
.SS "mlock(), mlock2() und munlock()"
\fBmlock\fP() sperrt Seiten im Adressbereich, der bei \fIadr\fP beginnt und sich
über \fILänge\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
entsperrt werden.
.PP
.\" commit a8ca5d0ecbdde5cc3d7accacbd69968b0c98764e
.\" commit de60f5f10c58d4f34b68622442c0e04180367f3f
.\" commit b0f205c2a3082dd9081f9a94e50658c5fa906ff1
\fBmlock2\fP() sperrt auch Seiten im Adressbereich, der bei \fIadr\fP beginnt und
sich über \fILänge\fP Byte erstreckt. Der Status der Seiten, die in dem
angegebenen Adressbereichs nach einem erfolgreichen Aufruf enthalten sind,
hängt vom Wert des \fISchalter\fP\-Arguments ab.
.PP
Das Argument \fISchalter\fP kann entweder 0 oder die folgende Konstante sein:
.TP
\fBMLOCK_ONFAULT\fP
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.
.PP
.PP
Wenn \fIflags\fP 0 ist, verhält sich \fBmlock2\fP() genau so wie \fBmlock\fP().
.PP
\fBmunlock\fP() entsperrt Seiten im Adressbereich, der mit \fIadr\fP beginnt und
sich über \fILänge\fP Byte erstreckt. Nach diesem Aufruf können alle Seiten,
die einen Teil des angegebenen Speicherbereichs umfassen, erneut vom Kernel
in externen Auslagerungsspeicher ausgelagert werden.
.SS "mlockall() und munlockall()"
\fBmlockall\fP() 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 \fBmlockall\fP() erfolgreich beendet wird. Es wird darüber
hinaus garantiert, dass die Seiten solange im RAM bleiben, bis sie wieder
entsperrt werden.
.PP
Das Argument \fISchalter\fP wird mittels logischem bitweisem 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 gemappt
sind.
.TP
\fBMCL_FUTURE\fP
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.
.TP
\fBMCL_ONFAULT\fP (seit Linux 4.4)
Wird zusammen mit \fBMCL_CURRENT\fP, \fBMCL_FUTURE\fP oder beiden
verwandt. Markiert alle aktuellen (mit \fBMCL_CURRENT\fP) oder zukünftigen (mit
\fBMCL_FUTURE\fP) Mappings, dass sie Seiten sperren, wenn diese durch
Ausnahmebehandlungen hereingekommen sind. Bei der Verwendung mit
\fBMCL_CURRENT\fP, werden alle vorhandenen Seiten gesperrt, aber \fBmlockall\fP()
wird keine nicht vorhandenen Seiten durch Ausnahmebehandlungen
hereinbringen. Bei der Verwendung mit \fBMCL_FUTURE\fP 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. \fBMCL_ONFAULT\fP muss entweder mit
\fBMCL_CURRENT\fP, \fBMCL_FUTURE\fP oder beiden verwandt werden.
.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 die Stack\-Vergrößerung verweigern
und dem Prozess ein \fBSIGSEGV\fP\-Signal schicken.
.PP
\fBmunlockall\fP() entsperrt alle in den Addressraum des aufrufenden Prozesses
gemappten 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 neuer) Der Aufrufende hatte eine weiche
Ressourcenbegrenzung \fBRLIMIT_MEMLOCK\fP ungleich null, versuchte aber über
diese Grenze hinaus Speicher zu sperren. 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 älter) Der aufrufende Prozess versuchte, mehr als die Hälfte
des RAMs zu sperren.
.TP
\fBEPERM\fP
.\"SVr4 documents an additional EAGAIN error code.
Der Aufrufende ist nicht privilegiert, benötigt aber zur Durchführung der
angeforderten Aktionen Privilegien (\fBCAP_IPC_LOCK\fP).
.PP
Für \fBmlock\fP(), \fBmlock2\fP() und \fBmunlock\fP():
.TP
\fBEAGAIN\fP
Ein Teil des angegebenen Adressbereichs oder der gesamte Adressbereich
konnten nicht gesperrt werden.
.TP
\fBEINVAL\fP
Das Ergebnis der Addition \fIadr\fP+\fILänge\fP war kleiner als \fIadr\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 gemappt sind.
.TP
\fBENOMEM\fP
.\" I.e., the number of VMAs would exceed the 64kB maximum
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.)
.PP
Für \fBmlock2\fP():
.TP
\fBEINVAL\fP
Es wurden unbekannte \fISchalter\fP angegeben.
.PP
Für \fBmlockall\fP():
.TP
\fBEINVAL\fP
Es wurden entweder unbekannte \fISchalter\fP angegeben oder \fBMCL_ONFAULT\fP
wurde weder mit \fBMCL_FUTURE\fP noch mit \fBMCL_CURRENT\fP angegeben.
.PP
Für \fBmunlockall\fP():
.TP
\fBEPERM\fP
(Linux 2.6.8 und älter) Der Aufrufende war nicht privilegiert
(\fBCAP_IPC_LOCK\fP).
.SH VERSIONEN
\fBmlock2\fP() ist seit Linux 4.4 verfügbar. Glibc\-Unterstützung wurde in
Version 2.27 hinzugefügt.
.SH "KONFORM ZU"
POSIX.1\-2001, POSIX.1\-2008, SVr4.
.PP
mlock2() ist Linux\-spezifisch.
.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.
.PP
.\" 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 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.)
.PP
Echtzeitprozesse, die mittels \fBmlockall\fP() 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.
.PP
Speichersperren 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 (entsperrt). Die Einstellungen \fBMCL_FUTURE\fP und
\fBMCL_FUTURE | MCL_ONFAULT\fP in \fBmlockall\fP() werden nicht von einem
Kindprozess ererbt, der mittels \fBfork\fP(2) erzeugt wurde und werden während
eines \fBexecve\fP(2) gelöscht.
.PP
Beachten Sie, dass \fBfork\fP(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, \fBfork\fP(2) nicht nach einer \fBmlockall\fP()\- oder
\fBmlock\fP()\-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.
.PP
Die Speichersperrung wird automatisch entfernt, wenn der Adressbereich
mittels \fBmunmap\fP(2) entmappt wird.
.PP
Speichersperren werden nicht hochgezählt (»gestapelt«), das heißt, Seiten
die mehrmals durch den Aufruf von \fBmlockall\fP(), \fBmlock2\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
gemappt wurden, bleiben solange im RAM gesperrt, wie sie mindestens an einem
Ort oder durch einen Prozess gesperrt sind.
.PP
Wenn einem Aufruf von \fBmlockall\fP(), der den Schalter \fBMCL_FUTURE\fP nutzt,
ein weiterer Aufruf folgt, der diesen Schalter nicht angibt, gehen die durch
den Aufruf von \fBMCL_FUTURE\fP erwirkten Änderungen verloren.
.PP
Der Schalter \fBMLOCK_ONFAULT\fP von \fBmlock2\fP() und der Schalter
\fBMCL_ONFAULT\fP von \fBmlockall\fP() 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.
.SS Linux\-Anmerkungen
Unter Linux runden \fBmlock\fP(), \fBmlock2\fP() und \fBmunlock\fP() \fIadr\fP
automatisch zur nächsten Seitengrenze ab. Da aber die POSIX.1\-Spezifikation
von \fBmlock\fP() und \fBmunlock\fP() Implementierungen gestattet, welche die
Ausrichtung von \fIadr\fP an Seitengrenzen fordern, sollten portable
Anwendungen die Ausrichtung sicherstellen.
.PP
Das Feld \fIVmLck\fP der Linux\-spezifischen Datei \fI/proc/[PID]/status\fP gibt
an, wie viele Kilobyte Speicher der Prozess mit der Kennung \fIPID\fP mittels
\fBmlock\fP(), \fBmlock2\fP(), \fBmlockall\fP() und \fBmmap\fP(2) mit dem Schalter
\fBMAP_LOCKED\fP gesperrt hat.
.SS "Grenzen und Zugriffsrechte"
Bis einschließlich Linux 2.6.8 muss ein Prozess privilegiert sein
(\fBCAP_IPC_LOCK\fP), um Speicher zu sperren. Die weiche Systembegrenzung
\fBRLIMIT_MEMLOCK\fP bestimmt einen Speicher\-Schwellwert, den der Prozess
sperren darf.
.PP
Seit Linux 2.6.9 kann ein privilegierter Prozess unbegrenzt Speicher
sperren. Die weiche Systembegrenzung \fBRLIMIT_MEMLOCK\fP legt stattdessen
fest, wieviel Speicher ein nicht privilegierter Prozess sperren darf.
.SH FEHLER
.\" commit 0cf2f6f6dc605e587d2c1120f295934c77e810e8
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
\fBCAP_IPC_LOCK\fP), das die gesperrten Bytes, die einer überlappenden (falls
vorhanden) und durch \fIadr\fP und \fILänge\fP 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 \fBRLIMIT_MEMLOCK\fP überschritt, führen. Damit
konnten dann \fBmlock\fP() und \fBmlock2\fP() fehlschlagen, obwohl die Anfragen
hätten erfolgreich sein sollen. Dieser Fehler wurde in Linux 4.9 behoben.
.PP
In den Linux\-Kerneln 2.4.x bis einschließlich 2.4.17 bewirkte ein Fehler,
dass der Schalter \fBMCL_FUTURE\fP von \fBmlockall\fP() über einen Aufruf von
\fBfork\fP(2) vererbt wurde. Dies wurde in Kernel 2.4.18 behoben.
.PP
.\" 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 angetroffen wird.
.SH "SIEHE AUCH"
\fBmincore\fP(2), \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 5.04 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 \%https://www.kernel.org/doc/man\-pages/.
.SH ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von
Hanno Wagner ,
Martin Schulze ,
Michaela Hohenner ,
Martin Eberhard Schauer ,
Mario Blättermann
und
Helge Kreutzmann
erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License Version 3
.UE
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
.MT debian-l10n-german@\:lists.\:debian.\:org
Mailingliste der Übersetzer
.ME .