MUNMAP(3P)

💖 MUNMAP(3P) — POSIX Programmer's Manual 💖

okay bestie, welcome to the POSIX Programmer's Manual page for munmap. quick vibe check first tho ✨

🌸 PROLOG 🌸

so like, this manual page is part of the POSIX Programmer's Manual, okay? and the tea is: the Linux implementation of this interface may differ (so if you're on Linux, go consult the corresponding Linux manual page for the actual details of Linux behavior), or honestly the interface may not even be implemented on Linux at all. no cap. 🙈

---

✨ NAME ✨

munmap — unmap pages of memory 🗺️💔

---

🎀 SYNOPSIS 🎀

#include <sys/mman.h>

int munmap(void *addr, size_t len);

---

🦋 DESCRIPTION 🦋

so the munmap() function shall remove any mappings for those entire pages containing any part of the address space of the process, starting at addr and continuing for len bytes. and then? further references to these pages shall result in the generation of a SIGSEGV signal to the process. 💀 yes really, that's the consequence, it's giving "you asked for it."

if there are no mappings in the specified address range, then munmap() has no effect. it's just out here doing nothing, minding its business. 💅

the implementation may require that addr be a multiple of the page size as returned by sysconf().

if a mapping to be removed was private, any modifications made in this address range shall be discarded. bye bye edits 👋

any memory locks (see mlock() and mlockall()) associated with this address range shall be removed, as if by an appropriate call to munlock().

now this next part is the typed memory object lore 🧚: if a mapping removed from a typed memory object causes the corresponding address range of the memory pool to be inaccessible by any process in the system except through allocatable mappings (that is, mappings of typed memory objects opened with the POSIX_TYPED_MEM_MAP_ALLOCATABLE flag), then that range of the memory pool shall become deallocated and may become available to satisfy future typed memory allocation requests.

but a mapping removed from a typed memory object opened with the POSIX_TYPED_MEM_MAP_ALLOCATABLE flag shall not affect in any way the availability of that typed memory for allocation. periodt. ✋

⚠️ and here's the warning bestie: the behavior of this function is unspecified if the mapping was not established by a call to mmap(). like, don't do that. that's not your moment. 😭

---

💅 RETURN VALUE 💅

upon successful completion, munmap() shall return 0 🎉; otherwise, it shall return -1 and set errno to indicate the error.

---

🔥 ERRORS 🔥

the munmap() function shall fail if:

• EINVAL — addresses in the range [addr,addr+len) are outside the valid range for the address space of a process.
• EINVAL — the len argument is 0.

the munmap() function may fail if:

• EINVAL — the addr argument is not a multiple of the page size as returned by sysconf().

and just so you know, the following sections are informative. 👀

---

🌈 EXAMPLES 🌈

None. (literally nothing here, bestie, move along 💀)

---

⭐ APPLICATION USAGE ⭐

None. (again, empty, it's giving minimal effort but we respect it 🫶)

---

👑 RATIONALE 👑

the munmap() function corresponds to SVR4, just as the mmap() function does. iconic lineage honestly.

so it's possible that an application has applied process memory locking to a region that contains shared memory. if this has occurred, the munmap() call ignores those locks and, if necessary, causes those locks to be removed.

most implementations require that addr is a multiple of the page size as returned by sysconf().

---

🍓 FUTURE DIRECTIONS 🍓

None. (nothing coming, the future is quiet 💜)

---

🧚 SEE ALSO 🧚

mlock(), mlockall(), mmap(), posix_typed_mem_open(), sysconf()

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!! 🎀✨ this one's brought to you by IEEE/The Open Group, dated 2017, and honestly? they ate. go unmap responsibly, munmap(3P) out. 💅🦋