Provided by: manpages-fr-dev_3.32d0.2p4-1_all bug

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  (Linux  2.6.9  et plus récents) L'appelant n'était pas privilégié (CAP_IPC_LOCK) et
              sa limite souple RLIMIT_MEMLOCK était à 0.

       EPERM  (Linux 2.6.8 et précédents) L'appelant  n'a  pas  les  privilèges  appropriés  pour
              appeler munlockall(). Sous Linux, la capacité CAP_IPC_LOCK est nécessaire.

       Pour mlock() et munlock() :

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

       EINVAL len est négatif.

       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.

       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.32 du projet man-pages Linux.  Une  description
       du  projet  et  des  instructions  pour  signaler  des  anomalies  peuvent être trouvées à
       l'adresse <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

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

       Christophe  Blaess  <URL:http://www.blaess.fr/christophe/>   (1996-2003),   Alain   Portal
       <URL: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> ».