Provided by: manpages-fr-dev_3.65d1p1-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  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> ».