---

   munmap    ( 2 )

---

Примечание (Note)

Memory mapped by mmap() is preserved across fork(2), with the
       same attributes.

       A file is mapped in multiples of the page size.  For a file that
       is not a multiple of the page size, the remaining bytes in the
       partial page at the end of the mapping are zeroed when mapped,
       and modifications to that region are not written out to the file.
       The effect of changing the size of the underlying file of a
       mapping on the pages that correspond to added or removed regions
       of the file is unspecified.

       On some hardware architectures (e.g., i386), PROT_WRITE implies
       PROT_READ.  It is architecture dependent whether PROT_READ
       implies PROT_EXEC or not.  Portable programs should always set
       PROT_EXEC if they intend to execute code in the new mapping.

       The portable way to create a mapping is to specify addr as 0
       (NULL), and omit MAP_FIXED from flags.  In this case, the system
       chooses the address for the mapping; the address is chosen so as
       not to conflict with any existing mapping, and will not be 0.  If
       the MAP_FIXED flag is specified, and addr is 0 (NULL), then the
       mapped address will be 0 (NULL).

       Certain flags constants are defined only if suitable feature test
       macros are defined (possibly by default): _DEFAULT_SOURCE with
       glibc 2.19 or later; or _BSD_SOURCE or _SVID_SOURCE in glibc 2.19
       and earlier.  (Employing _GNU_SOURCE also suffices, and requiring
       that macro specifically would have been more logical, since these
       flags are all Linux-specific.)  The relevant flags are:
       MAP_32BIT, MAP_ANONYMOUS (and the synonym MAP_ANON),
       MAP_DENYWRITE, MAP_EXECUTABLE, MAP_FILE, MAP_GROWSDOWN,
       MAP_HUGETLB, MAP_LOCKED, MAP_NONBLOCK, MAP_NORESERVE,
       MAP_POPULATE, and MAP_STACK.

       An application can determine which pages of a mapping are
       currently resident in the buffer/page cache using mincore(2).

   Using MAP_FIXED safely
       The only safe use for MAP_FIXED is where the address range
       specified by addr and length was previously reserved using
       another mapping; otherwise, the use of MAP_FIXED is hazardous
       because it forcibly removes preexisting mappings, making it easy
       for a multithreaded process to corrupt its own address space.

       For example, suppose that thread A looks through /proc/<pid>/maps
       in order to locate an unused address range that it can map using
       MAP_FIXED, while thread B simultaneously acquires part or all of
       that same address range.  When thread A subsequently employs
       mmap(MAP_FIXED), it will effectively clobber the mapping that
       thread B created.  In this scenario, thread B need not create a
       mapping directly; simply making a library call that, internally,
       uses dlopen(3) to load some other shared library, will suffice.
       The dlopen(3) call will map the library into the process's
       address space.  Furthermore, almost any library call may be
       implemented in a way that adds memory mappings to the address
       space, either with this technique, or by simply allocating
       memory.  Examples include brk(2), malloc(3), pthread_create(3),
       and the PAM libraries ⟨http://www.linux-pam.org⟩.

       Since Linux 4.17, a multithreaded program can use the
       MAP_FIXED_NOREPLACE flag to avoid the hazard described above when
       attempting to create a mapping at a fixed address that has not
       been reserved by a preexisting mapping.

   Timestamps changes for file-backed mappings
       For file-backed mappings, the st_atime field for the mapped file
       may be updated at any time between the mmap() and the
       corresponding unmapping; the first reference to a mapped page
       will update the field if it has not been already.

       The st_ctime and st_mtime field for a file mapped with PROT_WRITE
       and MAP_SHARED will be updated after a write to the mapped
       region, and before a subsequent msync(2) with the MS_SYNC or
       MS_ASYNC flag, if one occurs.

   Huge page (Huge TLB) mappings
       For mappings that employ huge pages, the requirements for the
       arguments of mmap() and munmap() differ somewhat from the
       requirements for mappings that use the native system page size.

       For mmap(), offset must be a multiple of the underlying huge page
       size.  The system automatically aligns length to be a multiple of
       the underlying huge page size.

       For munmap(), addr, and length must both be a multiple of the
       underlying huge page size.

   C library/kernel differences
       This page describes the interface provided by the glibc mmap()
       wrapper function.  Originally, this function invoked a system
       call of the same name.  Since kernel 2.4, that system call has
       been superseded by mmap2(2), and nowadays the glibc mmap()
       wrapper function invokes mmap2(2) with a suitably adjusted value
       for offset.