отображать или отменять отображение файлов или устройств в память (map or unmap files or devices into memory)
Примечание (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.
