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);
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. (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.23 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> ».