Provided by: manpages-fr-dev_3.07.1-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() :

       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.  (Voir   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 se
       soit terminé. (Soyez toutefois conscient que le mode suspendu  sur  les
       portables  et certains ordinateurs de bureau sauvegarde 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.

   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), capabilities(7)

COLOPHON

       Cette  page  fait  partie  de  la  publication 3.07 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

       Cette page de manuel a été traduite  et  mise  à  jour  par  Christophe
       Blaess  <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
       Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et  mise  à
       disposition sur http://manpagesfr.free.fr/.

       Les mises à jour et corrections de la version présente dans Debian sont
       directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
       francophone de traduction de Debian.

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