Ubuntu Manpage: mlock, mlock2, munlock, mlockall, munlockall - Verrouiller et déverrouiller la mémoire

nom
synopsis
description
valeur renvoyée
erreurs
versions
conformité
notes
bogues
voir aussi
colophon
traduction

NOM

       mlock, mlock2, munlock, mlockall, munlockall - Verrouiller et déverrouiller la mémoire

SYNOPSIS

       #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);

DESCRIPTION

mlock(), mlock2() et mlockall() verrouillent tout ou partie de l'espace d'adressage du processus appelant
dans la mémoire physique pour empêcher cette mémoire d'être évincée dans l'espace d'échange (swap).

munlock() et munlockall() ont l'effet inverse, respectivement déverrouillant une partie ou l'ensemble de
l'espace d'adressage du processus appelant, afin que les pages dans la zone indiquée puissent à nouveau
être évincées dans l'espace d'échange si le gestionnaire de mémoire du noyau l'exige.

Le verrouillage et le déverrouillage de la mémoire s'effectuent sur des unités de page entière.

mlock(), mlock2() et munlock()
mlock() verrouille les pages sur len octets à partir de l'adresse addr. Toutes les pages qui contiennent
une partie de la zone mémoire indiquée ont la garantie de résider en mémoire principale quand l'appel
réussit ; elles ont la garantie de rester en mémoire principale jusqu'à leur déverrouillage.

mlock() verrouille aussi les pages de la plage indiquée sur len octets à partir de l'adresse addr.
Néanmoins, l'état des pages contenues dans cette plage après un appel réussi dépendra de la valeur du
paramètre flags.

L'argument flags peut être 0 ou la constante suivante :

MLOCK_ONFAULT
Verrouiller les pages actuellement résidentes et marquer toute la plage pour que le reste des
pages non résidentes se verrouillent quand elles se remplissent d'erreurs de pagination.

Si flags vaut 0, mlock2() se comporte exactement comme mlock().

munlock() déverrouille la mémoire sur len octets à partir de l'adresse addr. Après cet appel, toutes les
pages contenant une partie de la zone mémoire indiquée peuvent de nouveau être évincées dans l'espace
d'échange par le noyau.

mlockall() et munlockall()
mlockall() verrouille toutes les pages projetées dans l'espace d'adressage du processus appelant. Cela
inclut les pages de code, de données et de pile, ainsi que les bibliothèques partagées, les données
utilisateur dans le noyau, la mémoire partagée, et les fichiers projetés en mémoire. Toutes les pages
projetées ont la garantie de résider en mémoire principale quand l'appel réussit ; elles ont la garantie
de rester en mémoire principale jusqu'à leur déverrouillage.

L'argument flags est composé d'un OU binaire avec les options suivantes :

MCL_CURRENT
Verrouiller toutes les pages actuellement projetées dans l'espace d'adressage du processus.

MCL_FUTURE
Verrouiller toutes les pages qui seront projetées dans l'espace d'adressage du processus dans le
futur. Il peut s'agir, par exemple, de nouvelles pages nécessitées par la croissance du tas et de
la pile, ou de nouveaux fichiers projetés en mémoire, ou des zones de mémoire partagée.

MCL_ONFAULT (depuis Linux 4.4)
Utilisé avec MCL_CURRENT, MCL_FUTURE ou les deux. Marquer toutes les projections actuelles (avec
MCL_CURRENT) ou futures (avec MCL_FUTURE) pour verrouiller les pages quand elles contiennent des
erreurs. Si on l'utilise avec MCL_CURRENT, toutes les pages présentes sont verrouillées mais
mlockall() ne rencontrera pas d'erreur sur des pages non présentes. Quand on l'utilise avec
MCL_FUTURE, toutes les projections futures seront marquées pour verrouiller les pages quand elles
rencontreront une erreur, mais elles ne seront pas remplies par le verrou lors de la création de
la projection. MCL_ONFAULT doit être utilisé avec MCL_CURRENT, MCL_FUTURE ou les deux.

Si MCL_FUTURE a été utilisé, un appel système ultérieur (p.ex. mmap(2), sbrk(2), malloc(3)) risque
d'échouer s'il cause un dépassement du nombre d'octets verrouillés autorisé (voir ci‐dessous). Dans les
mêmes circonstances, la croissance de la pile risque également d'échouer : le noyau interdira
l'augmentation de la pile et enverra le signal SIGSEGV au processus.

munlockall() déverrouille toutes les pages projetées dans l'espace d'adressage du processus appelant.

VALEUR RENVOYÉE

       S'ils réussissent, ces appels système  renvoient  0.  En  cas  d'erreur,  ils  renvoient  -1,  errno  est
       positionné adéquatement et les verrouillages de l'espace d'adressage du processus ne sont pas modifiés.

ERREURS

       ENOMEM (Linux  2.6.9 et plus récents) L'appelant avait une limite souple RLIMIT_MEMLOCK non nulle, mais a
              tenté de verrouiller plus de mémoire que la quantité autorisée. Cette limite n'est pas imposée  si
              le processus est privilégié (CAP_IPC_LOCK).

       ENOMEM (Linux  2.4  et  précédents) Le processus appelant a essayé de verrouiller plus de la moitié de la
              mémoire vive.

       EPERM  L'appelant n'est pas  privilégié  mais  a  besoin  de  droits  (CAP_IPC_LOCK)  pour  réaliser  les
              opérations demandées.

       Pour mlock(), mlock2() et munlock() :

       EAGAIN Une partie (ou l'ensemble) de l'espace d'adressage indiqué n'a pas pu être verrouillée.

       EINVAL La  somme  de addr+len était inférieure à addr (l'addition aurait pu conduire à un dépassement par
              exemple).

       EINVAL (Pas sous Linux) addr n'est pas un multiple de la taille de la page.

       ENOMEM Une partie de la zone indiquée ne correspond pas à des pages projetées dans  l'espace  d'adressage
              du processus.

       ENOMEM Le verrouillage ou le déverrouillage d'une région ferait dépasser le nombre maximum de projections
              permises ayant des attributs distincts (comme verrouillé contre  déverrouillé).  Par  exemple,  le
              déverrouillage  d'une  plage  située au milieu d'une projection actuellement verrouillée donnerait
              trois projections : deux verrouillées de chaque côté et une déverrouillée au milieu.

       Pour mlock2() :

       EINVAL Des flags inconnus étaient demandés.

       Pour mlockall() :

       EINVAL Des flags inconnus ont été indiqués ou MCL_ONFAULT a été indiqué sans MCL_FUTURE ou MCL_CURRENT.

       Pour munlockall() :

       EPERM  (Linux 2.6.8 et précédents) L'appelant n'est pas privilégié (CAP_IPC_LOCK).

VERSIONS

       mlock2() est disponible depuis Linux 4.4 ; la glibc le gère depuis la version 2.27.

CONFORMITÉ

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

       mlock2() est spécifique à Linux.

       Sur  les  systèmes  POSIX  où  mlock()  et  munlock()   sont   disponibles,   la   constante   symbolique
       _POSIX_MEMLOCK_RANGE est définie dans <unistd.h> et le nombre d'octets par page peut être déterminé grâce
       à la constante PAGESIZE si définie dans <limits.h> ou en appelant sysconf(_SC_PAGESIZE).

       Sur les systèmes POSIX sur lesquels mlockall() et munlockall() sont disponibles, la constante  symbolique
       _POSIX_MEMLOCK  est  définie  dans  <unistd.h>  comme  étant  une valeur supérieure à 0. (Consultez aussi
       sysconf(3).)

NOTES

Il y a deux domaines principaux d'applications du verrouillage de pages : les algorithmes en temps réel
et le traitement de données confidentielles. Les applications temps réel réclament un comportement
temporel déterministe, et la pagination est, avec l'ordonnancement, une cause majeure de délais imprévus.
Ces algorithmes basculent habituellement sur un ordonnancement temps‐réel avec sched_setscheduler(2). Les
logiciels de cryptographie manipulent souvent quelques octets hautement confidentiels, comme des mots de
passe ou des clés privées. À cause de la pagination, ces données secrètes risquent d'être transférées sur
un support physique où elles pourraient être lues par un ennemi longtemps après que le logiciel se soit
terminé. Soyez toutefois conscient que le mode suspendu sur les portables et certains ordinateurs de
bureau sauvegardent une copie de la mémoire sur le disque, quels que soient les verrouillages.

Les processus temps‐réel utilisant mlockall() pour éviter les délais dus à la pagination doivent réserver
assez de pages verrouillées pour la pile avant d'entrer dans la section temporellement critique, afin
qu'aucun défaut de page ne survienne lors d'un appel de fonction. Cela peut être obtenu en appelant une
fonction qui alloue une variable automatique suffisamment grande (comme un tableau) et écrit dans la
mémoire occupée par ce tableau afin de modifier ces pages de pile. Ainsi, suffisamment de pages seront
projetées pour la pile et pourront être verrouillées. Les écritures bidon permettent de s'assurer que
même les pages copiées à l'écriture ne causeront pas de défaut de page dans la section critique.

Les verrouillages de mémoire ne sont pas récupérés par un enfant lors d'un fork(2) et sont
automatiquement supprimés (déverrouillés) au cours d'un execve(2) ou lorsque le processus se termine. Les
paramètres MCL_FUTURE et MCL_FUTURE | MCL_ONFAULT de mlockall() ne sont pas récupérés par un enfant créé
par fork(2) et sont effacés au cours d'un execve(2).

Remarquez que fork(2) préparera l'espace d'adressage pour une opération copie-en-écriture. La conséquence
est que tout accès en écriture consécutif créera une erreur de pagination qui, elle-même, peut causer des
latences importantes dans un processus en temps réel. Il est donc crucial de ne pas appeler fork(2) après
des opérations mlockall() ou mlock() ; même à partir d'un thread qui tourne en priorité basse dans un
processus dont un thread tourne en priorité haute.

Le verrouillage de mémoire sur une zone est automatiquement enlevé si la zone est invalidée par
munmap(2).

Il n'y a pas d'empilement des verrouillages mémoire, ce qui signifie qu'une page verrouillée plusieurs
fois par des appels mlock(), mlock2() ou mlockall() sera libérée en un seul appel à munlock() pour la
zone mémoire correspondante ou par un appel à munlockall(). Les pages qui sont projetées à plusieurs
endroits ou par plusieurs processus restent verrouillées en mémoire vive tant qu'il y a au moins un
processus ou une zone qui les verrouille.

Si un appel à mlockall(), qui utilise l'attribut MCL_FUTURE, est suivi d'un autre appel qui n'indique pas
cet attribut, les changements effectués par l'appel MCL_FUTURE seront perdus.

L'attribut MLOCK_ONFAULT de mlock2() et celui MCL_ONFAULT de mlockall() permettent un verrouillage
efficace de la mémoire pour les applications qui ont à faire à de grandes projections où seulement une
(petite) partie des pages de la projection sont modifiées. Dans ce cas, le verrouillage de toutes les
pages d'une projection risquerait une sanction lourde de verrouillage de mémoire.

Notes pour Linux
Sous Linux, mlock(), mlock2() et munlock() arrondissent automatiquement addr à la frontière de page la
plus proche. Toutefois, la spécification POSIX.1 de mlock() et de munlock() permet à l'implémentation
d'imposer que addr soit alignée sur une frontière de page. Les applications portables devraient s'en
assurer.

Le champ VmLck du fichier /proc/PID/status spécifique à Linux indique combien de kilooctets de mémoire le
processus d'identifiant PID a verrouillé en utilisant mlock(), mlock2(), mlockall() et MAP_LOCKED de
mmap(2).

Limites et permissions
Sous Linux 2.6.8 et précédents, un processus doit être privilégié (CAP_IPC_LOCK) pour verrouiller de la
mémoire et la limite souple RLIMIT_MEMLOCK définit le nombre maximal d'octets que le processus peut
verrouiller en mémoire.

Depuis Linux 2.6.9, aucune limite n'est placée sur la quantité de mémoire pouvant être verrouillée par un
processus privilégié, et la limite souple RLIMIT_MEMLOCK définit la quantité maximale de mémoire pouvant
être verrouillée par un processus non privilégié.

BOGUES

       Dans  Linux  4.8  et  antérieurs, un bogue dans le calcul par le noyau de la mémoire verrouillée pour les
       processus non privilégiés (à savoir sans CAP_IPC_LOCK) faisait que si la région indiquée par addr et  len
       incluait  un  verrou  existant, les octets déjà verrouillés dans la région incluante étaient comptés deux
       fois lors de la vérification de leur atteinte de limite. Un  tel  double  comptage  calculerait  mal  une
       valeur de « mémoire verrouillée totale » du processus qui a dépassé la limite RLIMIT_MEMLOCK, si bien que
       mlock()  et mlock2() échoueraient sur des requêtes qui auraient dû réussir. Ce bogue a été  corrigé  dans
       Linux 4.9.

       Dans  les  noyaux  Linux  de  la branche 2.4 jusqu'à 2.4.17 inclus, le paramètre MCL_FUTURE de mlockall()
       était hérité par l'enfant après un fork(2) en raison d'un bogue. Cela a été corrigé dans le noyau 2.4.18.

       Depuis le noyau 2.6.9, si un processus privilégié appelle mlockall(MCL_FUTURE) et réduit  ses  privilèges
       plus  tard  (perd  la  capacité  CAP_IPC_LOCK,  par  exemple  en  prenant  un  UID effectif non nul), les
       allocations de mémoires suivantes (p.ex. mmap(2), brk(2)) échoueront  si  la  limite  RLIMIT_MEMLOCK  est
       dépassée.

VOIR AUSSI

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

COLOPHON

       Cette page fait partie de la publication 5.10 du projet man-pages Linux. Une description du projet et des
       instructions pour signaler des anomalies et la dernière version de cette page  peuvent  être  trouvées  à
       l'adresse https://www.kernel.org/doc/man-pages/.

TRADUCTION

       La   traduction   française   de   cette   page   de   manuel   a   été   créée   par  Christophe  Blaess
       <https://www.blaess.fr/christophe/>,   Stéphan   Rafin   <stephan.rafin@laposte.net>,   Thierry   Vignaud
       <tvignaud@mandriva.com>,  François  Micaux,  Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard
       <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)   <jean-luc.coulon@wanadoo.fr>,   Julien   Cristau
       <jcristau@debian.org>,      Thomas      Huriaux      <thomas.huriaux@gmail.com>,     Nicolas     François
       <nicolas.francois@centraliens.net>,    Florentin    Duneau    <fduneau@gmail.com>,     Simon     Paillard
       <simon.paillard@resel.enst-bretagne.fr>,     Denis    Barbier    <barbier@debian.org>,    David    Prévot
       <david@tilapin.org> et Jean-Philippe MENGUAL <jpmengual@debian.org>

       Cette traduction est une documentation libre ; veuillez vous reporter à la  GNU  General  Public  License
       version 3   ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩   concernant   les  conditions  de  copie  et  de
       distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel,  veuillez  envoyer  un  message  à
       debian-l10n-french@lists.debian.org ⟨⟩.