MLOCKALL(3POSIX)

💖 MLOCKALL(3POSIX) — bestie edition 💖

okay so first things first, this page lives in the POSIX Programmer's Manual (the <rainbow>POSIX Programmer's Manual</rainbow>, yes, that one 💅). heads up tho: the Linux implementation of this interface may differ — so if you're on Linux, go peek at the corresponding Linux manual page for the deets on Linux behavior. or, plot twist, the interface might not even be implemented on Linux at all 🙈. either way, we ball.

---

✨ NAME ✨

mlockall, munlockall — lock/unlock the address space of a process (REALTIME)

---

🎀 SYNOPSIS 🎀

#include <sys/mman.h>

int mlockall(int flags);
int munlockall(void);

---

🦋 DESCRIPTION 🦋

so mlockall() shall cause all of the pages mapped by the address space of a process to be memory-resident until they get unlocked, or until the process exits, or until it execs another process image. yeah. the whole address space. main character energy fr.

the flags argument is the vibe check that decides which pages get locked:

• the ones currently mapped by the process's address space,
• the ones that get mapped in the future,
• or both, because why choose 💅.

and flags is built from the bitwise-inclusive OR of one or more of these symbolic constants, all defined in <sys/mman.h>:

• MCL_CURRENT — lock all of the pages currently mapped into the address space of the process. right now. present tense. slay.
• MCL_FUTURE — lock all of the pages that become mapped into the address space of the process in the future, at the moment those mappings are established. it's giving ✨planning ahead✨.

⚠️ okay important one, no cap: if MCL_FUTURE is specified, and that automatic locking of future mappings eventually causes the amount of locked memory to exceed the amount of available physical memory, or any other implementation-defined limit, then the behavior is implementation-defined. and the way the implementation tells the application about these situations is also implementation-defined. so like... it's a mystery, and the mystery is defined by whoever implemented it 🫠.

now for munlockall() — it shall unlock all currently mapped pages of the address space of the process. any pages that become mapped into the address space after a call to munlockall() shall not be locked, unless there's an intervening call to mlockall() specifying MCL_FUTURE, or a subsequent call to mlockall() specifying MCL_CURRENT. so like, you have to actually ask again, bestie.

also: if pages mapped into the address space of the process are also mapped into the address spaces of other processes, and those other processes locked them? their locks shall be unaffected by a call by this process to munlockall(). not your locks, not your problem 💅.

upon successful return from the mlockall() function that specifies MCL_CURRENT, all currently mapped pages of the address space of the process shall be memory-resident and locked. upon return from the munlockall() function, all currently mapped pages of the address space of the process shall be unlocked with respect to the address space of the process. and the memory residency of unlocked pages? unspecified. we simply don't know. it's a surprise 🌸.

and lastly — appropriate privileges are required to lock process memory with mlockall(). you can't just walk in here and lock memory, you need the credentials, iykyk 👑

---

💜 RETURN VALUE 💜

upon successful completion, mlockall() shall return a value of zero. otherwise? no additional memory shall be locked, and the function shall return a value of -1 and set errno to indicate the error. also, the effect of failure of mlockall() on previously existing locks in the address space is unspecified 😭.

if it's supported by the implementation, munlockall() shall always return a value of zero. otherwise, it shall return a value of -1 and set errno to indicate the error.

---

🔥 ERRORS 🔥

mlockall() shall fail if:

• EAGAIN — some or all of the memory identified by the operation could not be locked when the call was made. it tried, it really did 💀.
• EINVAL — the flags argument is zero, or it includes unimplemented flags. zero flags is not a vibe.

mlockall() may fail if:

• ENOMEM — locking all of the pages currently mapped into the address space of the process would exceed an implementation-defined limit on the amount of memory that the process may lock. too much, bestie, the limit said no 🙈.
• EPERM — the calling process does not have appropriate privileges to perform the requested operation. no privileges, no locking, periodt.

📌 the following sections are informative.

---

🌈 EXAMPLES 🌈

none. (yes, literally. nothing here. it's giving minimalist 🎀)

---

🧚 APPLICATION USAGE 🧚

none. (again! the silence is iconic ✨)

---

⭐ RATIONALE ⭐

none. (three for three, we love a consistent queen 👑)

---

🌸 FUTURE DIRECTIONS 🌸

none. (the future is... empty. slay.)

---

💫 SEE ALSO 💫

exec, exit(), fork(), mlock(), munmap()

and from the Base Definitions volume of POSIX.1‐2017: <sys_mman.h> 🫶

---

📜 COPYRIGHT 📜

portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. in the event of any discrepancy between this version and the original IEEE and The Open Group Standard — the original IEEE and The Open Group Standard is the referee document. the original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. to report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

and that's the whole page, bestie 💖 that was IEEE/The Open Group, 2017, dropping MLOCKALL(3POSIX) like the icon it is 🎀✨🦋💅