Scroll to navigation

mlock(2) System Calls Manual mlock(2)

NOM

mlock, mlock2, munlock, mlockall, munlockall - Verrouiller et déverrouiller la mémoire

BIBLIOTHÈQUE

Bibliothèque C standard (libc, -lc)

SYNOPSIS

#include <sys/mman.h>
int mlock(const void addr[.len], size_t len);
int mlock2(const void addr[.len], size_t len, unsigned int flags);
int munlock(const void addr[.len], size_t len);
int mlockall(int flags);
int munlockall(void);

DESCRIPTION

mlock(), mlock2() et mlockall() verrouillent tout ou partie 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() and munlockall() perform the converse operation, unlocking part or all of the calling process's virtual address space, so that pages in the specified virtual address range may once more be swapped out if required by the kernel memory manager.

Le verrouillage et le déverrouillage de la mémoire s'effectuent sur des unités de page entière.

mlock(), mlock2() 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 ont la garantie de résider en mémoire principale quand l'appel réussit ; elles ont la garantie de rester en mémoire principale jusqu'à leur déverrouillage.

mlock() verrouille aussi les pages de la plage indiquée sur len octets à partir de l'adresse addr. Néanmoins, l'état des pages contenues dans cette plage après un appel réussi dépendra de la valeur du paramètre flags.

L'argument flags peut être 0 ou la constante suivante :

Verrouiller les pages actuellement résidentes et marquer toute la plage pour que le reste des pages non résidentes se verrouillent quand elles se remplissent d'erreurs de pagination.

Si flags vaut 0, mlock2() se comporte exactement comme mlock().

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() locks all pages mapped into the address space of the calling process. This includes the pages of the code, data, and stack segment, as well as shared libraries, user space kernel data, shared memory, and memory-mapped files. All mapped pages are guaranteed to be resident in RAM when the call returns successfully; the pages are guaranteed to stay in RAM until later unlocked.

L'argument flags est composé d'un OU binaire avec les options suivantes :

Verrouiller toutes les pages actuellement projetées dans l'espace d'adressage du processus.
Verrouiller toutes les pages qui seront projetées dans l'espace d'adressage du processus dans le futur. Il peut s'agir, 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.
Utilisé avec MCL_CURRENT, MCL_FUTURE ou les deux. Marquer toutes les projections actuelles (avec MCL_CURRENT) ou futures (avec MCL_FUTURE) pour verrouiller les pages quand elles contiennent des erreurs. Si on l'utilise avec MCL_CURRENT, toutes les pages présentes sont verrouillées mais mlockall() ne rencontrera pas d'erreur sur des pages non présentes. Quand on l'utilise avec MCL_FUTURE, toutes les projections futures seront marquées pour verrouiller les pages quand elles rencontreront une erreur, mais elles ne seront pas remplies par le verrou lors de la création de la projection. MCL_ONFAULT doit être utilisé avec MCL_CURRENT, MCL_FUTURE ou les deux.

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 également 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

On success, these system calls return 0. On error, -1 is returned, errno is set to indicate the error, and no changes are made to any locks in the address space of the process.

ERREURS

(mlock(), mlock2(), and munlock()) Some or all of the specified address range could not be locked.
(mlock(), mlock2(), and munlock()) The result of the addition addr+len was less than addr (e.g., the addition may have resulted in an overflow).
(mlock2()) Unknown flags were specified.
(mlockall()) Unknown flags were specified or MCL_ONFAULT was specified without either MCL_FUTURE or MCL_CURRENT.
(Pas sous Linux) addr n'est pas un multiple de la taille de la page.
(mlock(), mlock2(), and munlock()) Some of the specified address range does not correspond to mapped pages in the address space of the process.
(mlock(), mlock2(), and munlock()) Locking or unlocking a region would result in the total number of mappings with distinct attributes (e.g., locked versus unlocked) exceeding the allowed maximum. (For example, unlocking a range in the middle of a currently locked mapping would result in three mappings: two locked mappings at each end and an unlocked mapping in the middle.)
(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).
(Linux 2.4 et précédents) Le processus appelant a essayé de verrouiller plus de la moitié de la mémoire vive.
L'appelant n'est pas privilégié mais a besoin de droits (CAP_IPC_LOCK) pour réaliser les opérations demandées.
(munlockall()) (Linux 2.6.8 and earlier) The caller was not privileged (CAP_IPC_LOCK).

VERSIONS

mlock2() is available since Linux 4.4; glibc support was added in glibc 2.27.

STANDARDS

mlock(), munlock(), mlockall(), and munlockall(): POSIX.1-2001, POSIX.1-2008, SVr4.

mlock2() est spécifique à Linux.

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 du 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 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 récupérés par un enfant lors d'un fork(2) et sont automatiquement supprimés (déverrouillés) au cours d'un execve(2) ou lorsque le processus se termine. Les paramètres MCL_FUTURE et MCL_FUTURE | MCL_ONFAULT de mlockall() ne sont pas récupérés par un enfant créé par fork(2) et sont effacés au cours d'un execve(2).

Remarquez que fork(2) préparera l'espace d'adressage pour une opération copie-en-écriture. La conséquence est que tout accès en écriture consécutif créera une erreur de pagination qui, elle-même, peut causer des latences importantes dans un processus en temps réel. Il est donc crucial de ne pas appeler fork(2) après des opérations mlockall() ou mlock() ; même à partir d'un thread qui tourne en priorité basse dans un processus dont un thread tourne en priorité haute.

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 des appels mlock(), mlock2() 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 projetées à plusieurs endroits 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.

Si un appel à mlockall(), qui utilise l'attribut MCL_FUTURE, est suivi d'un autre appel qui n'indique pas cet attribut, les changements effectués par l'appel MCL_FUTURE seront perdus.

L'attribut MLOCK_ONFAULT de mlock2() et celui MCL_ONFAULT de mlockall() permettent un verrouillage efficace de la mémoire pour les applications qui ont à faire à de grandes projections où seulement une (petite) partie des pages de la projection sont modifiées. Dans ce cas, le verrouillage de toutes les pages d'une projection risquerait une sanction lourde de verrouillage de mémoire.

Notes pour Linux

Sous Linux, mlock(), mlock2() et munlock() arrondissent automatiquement addr à la frontière de page la plus proche. Toutefois, la spécification POSIX.1 de mlock() et de munlock() permet à l'implémentation d'imposer que addr soit alignée sur une frontière de page. Les applications portables devraient s'en assurer.

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 mlock(), mlock2(), mlockall() et MAP_LOCKED de mmap(2).

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 Linux 4.8 et antérieurs, un bogue dans le calcul par le noyau de la mémoire verrouillée pour les processus non privilégiés (à savoir sans CAP_IPC_LOCK) faisait que si la région indiquée par addr et len incluait un verrou existant, les octets déjà verrouillés dans la région incluante étaient comptés deux fois lors de la vérification de leur atteinte de limite. Un tel double comptage calculerait mal une valeur de « mémoire verrouillée totale » du processus qui a dépassé la limite RLIMIT_MEMLOCK, si bien que mlock() et mlock2() échoueraient sur des requêtes qui auraient dû réussir. Ce bogue a été corrigé dans Linux 4.9.

In the 2.4 series Linux kernels up to and including 2.4.17, a bug caused the mlockall() MCL_FUTURE flag to be inherited across a fork(2). This was rectified in Linux 2.4.18.

Since Linux 2.6.9, if a privileged process calls mlockall(MCL_FUTURE) and later drops privileges (loses the CAP_IPC_LOCK capability by, for example, setting its effective UID to a nonzero value), then subsequent memory allocations (e.g., mmap(2), brk(2)) will fail if the RLIMIT_MEMLOCK resource limit is encountered.

VOIR AUSSI

mincore(2), mmap(2), setrlimit(2), shmctl(2), sysconf(3), proc(5), capabilities(7)

TRADUCTION

La traduction française de cette page de manuel a été créée par Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot <david@tilapin.org> et Jean-Philippe MENGUAL <jpmengual@debian.org>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.

4 décembre 2022 Pages du manuel de Linux 6.02