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