mmap.2 (2010 09)

m
mmap(2) mmap(2)
shared between processes.
This implies the following:
• Any single range of a file cannot be mapped multiple times into different virtual address ranges.
• After the initial
MAP_SHARED mmap() of a file range, all subsequent
MAP_SHARED calls to
mmap() to map the same range of a file must either specify
MAP_VARIABLE in flags and inherit
the virtual address range the system has chosen for this range, or specify
MAP_FIXED with an
addr that corresponds exactly to the address chosen by the system for the initial mapping. Only
after all mappings for a file range have been destroyed can that range be mapped to a different
virtual address.
• In most cases, two separate calls to
mmap() cannot map overlapping ranges in a file. The vir-
tual address range reserved for a file range is determined at the time of the initial mapping of
the file range into a process address space. The system allocates only the virtual address range
necessary to represent the initial mapping. As long as the initial mapping exists, subsequent
attempts to map a different file range that includes any portion of the initial range may fail with
an [ENOMEM] error if an extended contiguous address range that preserves the mappings of the
initial range cannot be allocated.
• Separate calls to
mmap() to map contiguous ranges of a file do not necessarily return contiguous
virtual address ranges. The system may allocate virtual addresses for each call to mmap() on a
first available basis.
• The use of
MAP_FIXED is strongly discouraged because it is not portable. Using MAP_FIXED is
generally unsuccessful on this implementation, and when it is successful, it may prevent the sys-
tem from optimally allocating virtual address space.
MAP_FIXED is discouraged, but there are some applications which by design must fix pointer offsets into
file data. The application must map the file at a specific address in order for the file offsets embedded in
the file to make sense.
Processes cannot control the usage of global virtual address space, but they can control what happens
within their private data area. The PA-RISC version of HP-UX allows a single process to exclusively map
afile
MAP_SHARED into its private data space. When a process specifies MAP_SHARED
and MAP_FIXED
with a private data address (that is, second quadrant for 32-bit executable, third quadrant for 64-bit exe-
cutable), the kernel interprets this as an exclusive mapping of the file. The request will only succeed if no
other processes in the system currently have that file mapped through
MAP_SHARED. If the file is
already mapped the caller receives an [EBUSY] error. If the call is successful, the calling process is the
only process allowed to map that file using MAP_SHARED until it unmaps the file using
munmap().
Because it is exclusive, the
mmap() is not inherited across fork(). When a file is exclusively mapped
only MAP_PRIVATE mappings are allowed by other processes.
If a
MAP_PRIVATE mapping is created of a file for which a MAP_SHARED mapping exists, a separate
copy of a page for the MAP_PRIVATE mapping is created at the time of the first access to the page
through the private mapping.
APPLICATION USAGE
Use of
mmap() may reduce the amount of memory available to other memory allocation functions.
Use of
MAP_FIXED may result in unspecified behavior later in the use of brk(), sbrk(), malloc(),
and shmat(). The use of MAP_FIXED is discouraged, as it may prevent an implementation from mak-
ing the most effective use of resources.
The application must ensure correct synchronization when using
mmap() in conjunction with any other
file access method, such as read() and write(), standard input/output, and shmat().
The
mmap() function allows access to resources via address space manipulations, instead of
read()/write(). Once a file is mapped, all a process has to do to access it is use the data at the
address to which the file was mapped. Using pseudo-code to illustrate the way an existing program might
be changed to use mmap(), the following:
fildes = open(...)
lseek(fildes, some_offset)
read(fildes, buf, len)
/* use data in buf */
6 Hewlett-Packard Company − 6 − HP-UX 11i Version 3: September 2010