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