Provided by: manpages-de-dev_2.16-1_all bug

BEZEICHNUNG

       mlock, mlock2, munlock, mlockall, munlockall - Speicher ver- und entriegeln

ÜBERSICHT

       #include <sys/mman.h>

       int mlock(const void *addr, size_t len);
       int mlock2(const void *addr, size_t len, int flags);
       int munlock(const void *addr, size_t len);

       int mlockall(int flags);
       int munlockall(void);

BESCHREIBUNG

       mlock(),  mlock2()  und  mlockall() verriegeln 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 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(), mlock2() 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.

       mlock2()  verriegelt  auch Seiten im Adressbereich, der bei addr beginnt und sich über len
       Byte erstreckt. Der Status der Seiten,  die  einen  Teil  des  angegebenen  Adressbereichs
       enthalten, nach einem erfolgreichen Aufruf hängt vom Wert des flags-Arguments ab.

       Das Argument flags kann entweder 0 oder eine der folgenden Konstanten sein:

       MLOCK_ONFAULT
              Lock  pages  that  are  currently  resident  and  mark the entire range so that the
              remaining nonresident pages are locked when they are populated by a page fault.

       Wenn flags 0 ist, verhält sich mlock2() genau so wie mlock().

       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 Auslagerungsspeicher  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.

       MCL_ONFAULT (seit Linux 4.4)
                   Used together with MCL_CURRENT, MCL_FUTURE, or both. Mark  all  current  (with
                   MCL_CURRENT)   or  future  (with MCL_FUTURE)  mappings to lock pages when they
                   are faulted in. When used with MCL_CURRENT, all present pages are locked,  but
                   mlockall()   will  not  fault in non-present pages. When used with MCL_FUTURE,
                   all future mappings will be marked to lock pages when they are faulted in, but
                   they  will  not  be  populated  by  the  lock  when  the  mapping  is created.
                   MCL_ONFAULT must be used with either MCL_CURRENT or MCL_FUTURE or both.

       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(), mlock2() und munlock():

       EAGAIN Ein Teil des angegebenen Adressbereichs  oder  der  gesamte  Adressbereich  konnten
              nicht verriegelt werden.

       EINVAL Das  Ergebnis  der  Addition addr+len war kleiner als addr (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.

       ENOMEM Locking  or  unlocking  a  region would result in the total number of mappings with
              distinct attributes (e.g., locked versus unlocked)  exceeding the allowed  maximum.
              (For  example,  unlocking a range in the middle of a currently locked mapping would
              result in three mappings: two locked mappings at each end and an  unlocked  mapping
              in the middle.)

       Für mlock2():

       EINVAL Es wurden unbekannte Flags angegeben.

       Für mlockall():

       EINVAL Es  wurden  entweder  unbekannte  flags angegeben, oder MCL_ONFAULT wurde weder mit
              MCL_FUTURE noch mit MCL_CURRENT angegeben.

       Für munlockall():

       EPERM  (Linux 2.6.8 und früher) Der Aufrufende war nicht privilegiert (CAP_IPC_LOCK).

VERSIONEN

       mlock2()  ist  seit  Linux  4.4  verfügbar.  Glibc-Unterstützung  wurde  in  Version  2.27
       hinzugefügt.

KONFORM ZU

       POSIX.1-2001, POSIX.1-2008, SVr4.

       mlock2 () ist Linux-spezifisch.

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 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 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 fork(2) erzeugte Kindprozesse  vererbt  und
       durch  einen  Aufruf  von  execve(2)  oder  das  Ende  des  Prozesses automatisch entfernt
       (entriegelt). 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 wird, die  wiederum  hohe  Latenzen  für  Echtzeitprozesse
       hervorruft.   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  Speicherverriegelung  wird  automatisch  entfernt,  wenn  der  Adressbereich  mittels
       munmap(2) ausgeblendet 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
       eingeblendet  wurden,  bleiben  solange im RAM verriegelt, wie sie mindestens an einem Ort
       oder durch einen Prozess benötigt werden.

       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.

       The mlock2()  MLOCK_ONFAULT flag and the  mlockall()   MCL_ONFAULT  flag  allow  efficient
       memory locking for applications that deal with large mappings where only a (small) portion
       of pages in the mapping are touched. In such cases, locking all of the pages in a  mapping
       would incur a significant penalty for memory locking.

   Linux-Anmerkungen
       Unter  Linux  runden  mlock(),  mlock2()  und  munlock()  addr  automatisch  zur  nächsten
       Seitengrenze  ab.  Da  aber  die   POSIX.1-Spezifikation   von   mlock()   und   munlock()
       Implementierungen  gestattet,  welche  die  Ausrichtung von addr an Seitengrenzen fordern,
       sollten portable Anwendungen die Ausrichtung sicherstellen.

       Das Feld  VmLck  der  Linux-spezifischen  Datei  /proc/[PID]/status  gibt  an,  wie  viele
       Kilobytes  Speicher  der  Prozess mit der ID PID mittels mlock(), mlock2(), mlockall() und
       mmap(2) mit dem Schalter MAP_LOCKED verriegelt hat.

   Grenzen und Zugriffsrechte
       Bis einschließlich Linux 2.6.8 muss  ein  Prozess  privilegiert  sein  (CAP_IPC_LOCK),  um
       Speicher   zu  verriegeln.  Die  weiche  Systembegrenzung  RLIMIT_MEMLOCK  bestimmt  einen
       Speicher-Schwellwert, den der Prozess verriegeln darf.

       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 Linux 4.8 und  ältern  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  addr  und  len
       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  den  Linux-Kerneln  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 Kernel 2.4.18 behoben.

       Seit  Kernel  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 berührt wird.

SIEHE AUCH

       mincore(2), mmap(2), setrlimit(2), shmctl(2), sysconf(3), proc(5), capabilities(7)

KOLOPHON

       Diese  Seite  ist  Teil  der  Veröffentlichung  5.03  des  Projekts  Linux-man-pages. 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/.

Ü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  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>.