Provided by:
manpages-fr-dev_3.27fr1.4-1_all 
NOM
mlock, munlock, mlockall, munlockall - Verrouiller et deverrouiller la
memoire
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
memoire physique, pour empecher cette memoire d'etre evincee dans
l'espace d'echange (swap). munlock() et munlockall() ont l'effet
inverse, respectivement deverrouillant une partie ou l'ensemble de
l'espace d'adressage du processus appelant, afin que les pages dans la
zone indiquee puissent a nouveau etre evincees dans le swap si le
gestionnaire de memoire du noyau l'exige. Le verrouillage et le
deverrouillage de memoire se font par multiples d'une page.
mlock() et munlock()
mlock() verrouille les pages sur len octets a partir de l'adresse addr.
Toutes les pages qui contiennent une partie de la zone memoire indiquee
seront residentes en memoire principale quand l'appel reussit ; elles
resteront en memoire principale jusqu'a leur deverrouillage.
munlock() deverrouille la memoire sur len octets a partir de l'adresse
addr. Apres cet appel, toutes les pages contenant une partie de la zone
memoire indiquee peuvent de nouveau etre evincees dans l'espace
d'echange par le noyau.
mlockall() et munlockall()
mlockall() verrouille toutes les pages projetees dans l'espace
d'adressage du processus appelant. Cela inclut les pages de code, de
donnees et de pile, ainsi que les bibliotheques partagees, les donnees
utilisateur dans le noyau, la memoire partagee, et les fichiers
projetes en memoire. Toutes les pages projetees seront residentes en
memoire principale quand l'appel reussit ; elles resteront en memoire
principale jusqu'a leur deverrouillage.
L'argument flags est compose d'un OU binaire avec les options
suivantes :
MCL_CURRENT Verrouiller toutes les pages actuellement projetees dans
l'espace d'adressage du processus.
MCL_FUTURE Verrouiller toutes les pages qui seront projetees dans
l'espace d'adressage du processus dans le futur. Par
exemple, de nouvelles pages necessitees par la croissance
du tas et de la pile, ou de nouveaux fichiers projetes en
memoire, ou des zones de memoire partagee.
Si MCL_FUTURE a ete utilise, un appel systeme ulterieur (p.ex. mmap(2),
sbrk(2), malloc(3)) risque d'echouer s'il cause un depassement du
nombre d'octets verrouilles autorise (voir ci-dessous). Dans les memes
circonstances, la croissance de la pile risque de meme d'echouer : le
noyau interdira l'augmentation de la pile et enverra le signal SIGSEGV
au processus.
munlockall() deverrouille toutes les pages projetees dans l'espace
d'adressage du processus appelant.
VALEUR RENVOY'EE
S'ils reussissent, ces appels systeme renvoient 0. En cas d'erreur, ils
renvoient -1, errno contient le code d'erreur, et les verrouillages de
memoire du processus ne sont pas modifies.
ERREURS
ENOMEM (Linux 2.6.9 et plus recents) L'appelant avait une limite souple
RLIMIT_MEMLOCK non nulle, mais a tente de verrouiller plus de
memoire que la quantite autorisee. Cette limite n'est pas
imposee si le processus est privilegie (CAP_IPC_LOCK).
ENOMEM (Linux 2.4 et precedents) Le processus appelant a essaye de
verrouiller plus de la moitie de la memoire vive.
EPERM (Linux 2.6.9 et plus recents) L'appelant n'etait pas privilegie
(CAP_IPC_LOCK) et sa limite souple RLIMIT_MEMLOCK etait a 0.
EPERM (Linux 2.6.8 et precedents) L'appelant n'a pas les privileges
appropries pour appeler munlockall(). Sous Linux, la capacite
CAP_IPC_LOCK est necessaire.
Pour mlock() et munlock() :
EAGAIN Une partie (ou l'ensemble) de l'espace d'adressage indique n'a
pas pu etre verrouillee.
EINVAL len est negatif.
EINVAL (Pas sous Linux) addr n'est pas un multiple de la taille de
page.
ENOMEM Une partie de la zone indiquee ne correspond pas a des pages
projetees dans l'espace d'adressage du processus.
Pour mlockall() :
EINVAL Des flags inconnus etaient demandes.
Pour munlockall() :
EPERM (Linux 2.6.8 et precedents) L'appelant n'est pas privilegie
(CAP_IPC_LOCK).
CONFORMIT'E
POSIX.1-2001, SVr4.
DISPONIBILIT'E
Sur les systemes POSIX ou mlock() et munlock() sont disponibles, la
constante symbolique _POSIX_MEMLOCK_RANGE est definie dans <unistd.h>
et le nombre d'octets par page peut etre determine grace a la constante
PAGESIZE si definie dans <limits.h> ou en appelant
sysconf(_SC_PAGESIZE).
Sur les systemes POSIX sur lesquels mlockall() et munlockall() sont
disponibles, la constante symbolique _POSIX_MEMLOCK est definie dans
<unistd.h> comme etant une valeur superieure a 0. (Consultez aussi
sysconf(3).)
NOTES
Il y a deux domaines principaux d'applications au verrouillage de
pages : les algorithmes en temps reel, et le traitement de donnees
confidentielles. Les applications temps reel reclament un comportement
temporel deterministe, et la pagination est, avec l'ordonnancement, une
cause majeure de delais imprevus. Ces algorithmes basculent
habituellement sur un ordonnancement temps-reel avec
sched_setscheduler(2). Les logiciels de cryptographie manipulent
souvent quelques octets hautement confidentiels, comme des mots de
passe ou des cles privees. A cause de la pagination, ces donnees
secretes risquent d'etre transferees sur un support physique ou elles
pourraient etre lues par un ennemi longtemps apres que le logiciel
s'est termine. Soyez toutefois conscient que le mode suspendu sur les
portables et certains ordinateurs de bureau sauvegardent une copie de
la memoire sur le disque, quels que soient les verrouillages.
Les processus temps-reel utilisant mlockall() pour eviter les delais
dus a la pagination doivent reserver assez de pages verrouillees pour
la pile avant d'entrer dans la section temporellement critique, afin
qu'aucun defaut de page ne survienne lors d'un appel de fonction. Cela
peut etre obtenu en appelant une fonction qui alloue une variable
automatique suffisamment grande (comme un tableau) et ecrit dans la
memoire occupee par ce tableau afin de modifier ces pages de pile.
Ainsi, suffisamment de pages seront projetees pour la pile et pourront
etre verrouillees. Les ecritures bidon permettent de s'assurer que meme
les pages copiees a l'ecriture ne causeront pas de defaut de page dans
la section critique.
Les verrouillages de memoire ne sont pas herites par le fils lors d'un
fork(2), et sont automatiquement supprimes (deverrouilles) au cours
d'un execve(2) ou lorsque le processus termine.
Le verrouillage de memoire sur une zone est automatiquement enleve si
la zone est invalidee par munmap(2).
Il n'y a pas d'empilement des verrouillages memoire, ce qui signifie
qu'une page verrouillee plusieurs fois par mlock() ou mlockall() sera
liberee en un seul appel a munlock() pour la zone memoire
correspondante ou par un appel a munlockall(). Les pages qui sont
verrouillees par plusieurs zones, ou par plusieurs processus restent
verrouillees en memoire 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 a la
frontiere de page la plus proche. Toutefois, POSIX.1-2001 permet a
l'implementation d'imposer que addr soit alignee sur une frontiere de
page. Les programmes portables en prendront donc soin.
Le champ VmLck du fichier /proc/PID/status specifique a Linux indique
combien de kilooctets de memoire le processus appelant a verrouille en
utilisant les fonctions mlock(), mlockall(), shmctl(2) SHM_LOCK et
mmap(2) MAP_LOCKED.
Limites et permissions
Sous Linux 2.6.8 et precedents, un processus doit etre privilegie
(CAP_IPC_LOCK) pour verrouiller de la memoire, et la limite souple
RLIMIT_MEMLOCK definit le nombre maximal d'octets que le processus peut
verrouiller en memoire.
Depuis Linux 2.6.9, aucune limite n'est placee sur la quantite de
memoire pouvant etre verrouillee par un processus privilegie, et la
limite souple RLIMIT_MEMLOCK definit la quantite maximale de memoire
pouvant etre verrouillee par un processus non privilegie.
BOGUES
Dans les noyaux Linux de la branche 2.4 jusqu'a 2.4.17 inclus, le
parametre MCL_FUTURE de mlockall() etait herite par le fils apres un
fork(2) en raison d'un bogue. Cela a ete corrige dans le noyau 2.4.18.
Depuis le noyau 2.6.9, si un processus privilegie appelle
mlockall(MCL_FUTURE) et reduit ses privileges plus tard (perd la
capacite CAP_IPC_LOCK, par exemple en prenant un UID effectif non nul),
les allocations de memoires suivantes (p.ex. mmap(2), brk(2))
echoueront si la limite RLIMIT_MEMLOCK est depassee.
VOIR AUSSI
mmap(2), setrlimit(2), shmctl(2), sysconf(3), proc(5), capabilities(7)
COLOPHON
Cette page fait partie de la publication 3.27 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent etre trouvees a l'adresse
<URL:http://www.kernel.org/doc/man-pages/>.
TRADUCTION
Depuis 2010, cette traduction est maintenue a l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'equipe de traduction
francophone au sein du projet perkamon
<URL:http://perkamon.alioth.debian.org/>.
Christophe Blaess <URL:http://www.blaess.fr/christophe/> (1996-2003),
Alain Portal <URL:http://manpagesfr.free.fr/> (2003-2006). Julien
Cristau et l'equipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en ecrivant a
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir acces a la version anglaise de ce document
en utilisant la commande << man -L C <section> <page_de_man> >>.