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

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

Provided by: manpages-fr-dev_3.65d1p1-1_all

NOM

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

SYNOPSIS

       #include <sys/mman.h>

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

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

DESCRIPTION

mlock() et mlockall() verrouillent respectivement une partie et l'ensemble 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 le swap si le gestionnaire de mémoire du noyau l'exige. Le
verrouillage et le déverrouillage de mémoire se font par multiples d'une page.

mlock() 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 seront résidentes en mémoire principale quand l'appel réussit ;
elles resteront en mémoire principale jusqu'à leur déverrouillage.

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 seront résidentes en mémoire principale quand l'appel réussit ; elles resteront 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. 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.

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 de même 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 contient le
       code d'erreur, et les verrouillages de mémoire 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() 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 start et len était inférieure à start (l'addition aurait pu conduire à un  dépassement
              par exemple).

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

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

       Pour mlockall() :

       EINVAL Des flags inconnus étaient demandés.

       Pour munlockall() :

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

CONFORMITÉ

       POSIX.1-2001, SVr4.

DISPONIBILITÉ

       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 au 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 s'est
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 hérités par le fils lors d'un fork(2), et sont automatiquement
supprimés (déverrouillés) au cours d'un execve(2) ou lorsque le processus termine. L'attribut MCL_FUTURE
de mlockall() n'est pas hérité par un fils créé par fork(2), et est effacé au cours d'un execve(2).

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 mlock() 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 verrouillées par plusieurs zones, 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.

Notes sur Linux
Sous Linux, mlock() et munlock() arrondissent automatiquement addr à la frontière de page la plus proche.
Toutefois, POSIX.1-2001 permet à l'implémentation d'imposer que addr soit alignée sur une frontière de
page. Les programmes portables en prendront donc soin.

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 les fonctions mlock(), mlockall() et mmap(2)
MAP_LOCKED.

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  les  noyaux  Linux  de  la branche 2.4 jusqu'à 2.4.17 inclus, le paramètre MCL_FUTURE de mlockall()
       était hérité par le fils 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

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

COLOPHON

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

TRADUCTION

       Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a <http://po4a.alioth.debian.org/> par
       l'équipe de traduction francophone au sein du projet perkamon <http://perkamon.alioth.debian.org/>.

       Christophe      Blaess      <http://www.blaess.fr/christophe/>      (1996-2003),       Alain       Portal
       <http://manpagesfr.free.fr/>  (2003-2006).  Julien  Cristau  et  l'équipe  francophone  de  traduction de
       Debian (2006-2009).

       Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org>  ou  par
       un rapport de bogue sur le paquet manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C
       <section> <page_de_man> ».