1MMAP(2)                    Linux Programmer's Manual                   MMAP(2)
2
3
4

NAME

6       mmap, munmap - map or unmap files or devices into memory
7

SYNOPSIS

9       #include <sys/mman.h>
10
11       void *mmap(void *addr, size_t length, int prot, int flags,
12                  int fd, off_t offset);
13       int munmap(void *addr, size_t length);
14
15       See NOTES for information on feature test macro requirements.
16

DESCRIPTION

18       mmap()  creates a new mapping in the virtual address space of the call‐
19       ing process.  The starting address for the new mapping is specified  in
20       addr.   The  length argument specifies the length of the mapping (which
21       must be greater than 0).
22
23       If addr is NULL, then the kernel chooses the (page-aligned) address  at
24       which to create the mapping; this is the most portable method of creat‐
25       ing a new mapping.  If addr is not NULL, then the kernel takes it as  a
26       hint about where to place the mapping; on Linux, the kernel will pick a
27       nearby page boundary (but always above or equal to the value  specified
28       by /proc/sys/vm/mmap_min_addr) and attempt to create the mapping there.
29       If another mapping already exists there, the kernel picks a new address
30       that may or may not depend on the hint.  The address of the new mapping
31       is returned as the result of the call.
32
33       The contents of a file mapping (as opposed to an anonymous mapping; see
34       MAP_ANONYMOUS  below),  are  initialized using length bytes starting at
35       offset offset in the file (or other object) referred  to  by  the  file
36       descriptor  fd.  offset must be a multiple of the page size as returned
37       by sysconf(_SC_PAGE_SIZE).
38
39       After the mmap() call has returned, the file  descriptor,  fd,  can  be
40       closed immediately without invalidating the mapping.
41
42       The  prot  argument describes the desired memory protection of the map‐
43       ping (and must not conflict with the open mode of  the  file).   It  is
44       either  PROT_NONE  or  the  bitwise  OR of one or more of the following
45       flags:
46
47       PROT_EXEC  Pages may be executed.
48
49       PROT_READ  Pages may be read.
50
51       PROT_WRITE Pages may be written.
52
53       PROT_NONE  Pages may not be accessed.
54
55       The flags argument determines whether updates to the mapping are  visi‐
56       ble to other processes mapping the same region, and whether updates are
57       carried through to the underlying file.  This behavior is determined by
58       including exactly one of the following values in flags:
59
60       MAP_SHARED
61              Share this mapping.  Updates to the mapping are visible to other
62              processes mapping the same region, and (in  the  case  of  file-
63              backed  mappings)  are  carried  through to the underlying file.
64              (To precisely control when updates are carried  through  to  the
65              underlying file requires the use of msync(2).)
66
67       MAP_SHARED_VALIDATE (since Linux 4.15)
68              This  flag  provides the same behavior as MAP_SHARED except that
69              MAP_SHARED mappings ignore unknown flags in flags.  By contrast,
70              when  creating  a  mapping using MAP_SHARED_VALIDATE, the kernel
71              verifies all passed flags are known and fails the  mapping  with
72              the  error  EOPNOTSUPP  for unknown flags.  This mapping type is
73              also required to be  able  to  use  some  mapping  flags  (e.g.,
74              MAP_SYNC).
75
76       MAP_PRIVATE
77              Create  a private copy-on-write mapping.  Updates to the mapping
78              are not visible to other processes mapping the  same  file,  and
79              are  not carried through to the underlying file.  It is unspeci‐
80              fied whether changes made to the file after the mmap() call  are
81              visible in the mapped region.
82
83       Both  MAP_SHARED  and  MAP_PRIVATE  are  described  in POSIX.1-2001 and
84       POSIX.1-2008.  MAP_SHARED_VALIDATE is a Linux extension.
85
86       In addition, zero or more of the following values can be ORed in flags:
87
88       MAP_32BIT (since Linux 2.4.20, 2.6)
89              Put the mapping into  the  first  2  Gigabytes  of  the  process
90              address  space.   This  flag  is  supported  only on x86-64, for
91              64-bit programs.  It was added to  allow  thread  stacks  to  be
92              allocated  somewhere  in  the  first  2 GB  of  memory, so as to
93              improve context-switch performance on some early 64-bit  proces‐
94              sors.   Modern x86-64 processors no longer have this performance
95              problem, so use of this flag is not required on  those  systems.
96              The MAP_32BIT flag is ignored when MAP_FIXED is set.
97
98       MAP_ANON
99              Synonym for MAP_ANONYMOUS.  Deprecated.
100
101       MAP_ANONYMOUS
102              The mapping is not backed by any file; its contents are initial‐
103              ized to zero.  The fd argument is ignored; however, some  imple‐
104              mentations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is
105              specified, and portable applications should  ensure  this.   The
106              offset  argument  should  be  zero.  The use of MAP_ANONYMOUS in
107              conjunction with MAP_SHARED is supported  on  Linux  only  since
108              kernel 2.4.
109
110       MAP_DENYWRITE
111              This  flag  is ignored.  (Long ago—Linux 2.0 and earlier—it sig‐
112              naled that attempts to write to the underlying file should  fail
113              with  ETXTBUSY.   But  this  was  a  source of denial-of-service
114              attacks.)
115
116       MAP_EXECUTABLE
117              This flag is ignored.
118
119       MAP_FILE
120              Compatibility flag.  Ignored.
121
122       MAP_FIXED
123              Don't interpret addr as a hint: place  the  mapping  at  exactly
124              that address.  addr must be suitably aligned: for most architec‐
125              tures a multiple of the page size is sufficient;  however,  some
126              architectures may impose additional restrictions.  If the memory
127              region specified by addr and len overlaps pages of any  existing
128              mapping(s),  then the overlapped part of the existing mapping(s)
129              will be discarded.  If the specified  address  cannot  be  used,
130              mmap() will fail.
131
132              Software  that  aspires  to be portable should use the MAP_FIXED
133              flag with care, keeping in mind  that  the  exact  layout  of  a
134              process's  memory  mappings  is  allowed to change significantly
135              between kernel versions, C library versions, and operating  sys‐
136              tem  releases.   Carefully  read  the discussion of this flag in
137              NOTES!
138
139       MAP_FIXED_NOREPLACE (since Linux 4.17)
140              This flag provides behavior that is similar  to  MAP_FIXED  with
141              respect   to   the   addr   enforcement,  but  differs  in  that
142              MAP_FIXED_NOREPLACE never clobbers a preexisting  mapped  range.
143              If  the  requested range would collide with an existing mapping,
144              then this call fails with  the  error  EEXIST.   This  flag  can
145              therefore  be used as a way to atomically (with respect to other
146              threads) attempt to map an address range: one thread  will  suc‐
147              ceed; all others will report failure.
148
149              Note   that   older   kernels   which   do   not  recognize  the
150              MAP_FIXED_NOREPLACE flag will typically (upon detecting a colli‐
151              sion  with a preexisting mapping) fall back to a "non-MAP_FIXED"
152              type of behavior: they will return an address that is  different
153              from  the  requested  address.   Therefore,  backward-compatible
154              software should check the returned address against the requested
155              address.
156
157       MAP_GROWSDOWN
158              This  flag  is used for stacks.  It indicates to the kernel vir‐
159              tual memory system that the mapping should  extend  downward  in
160              memory.   The  return  address is one page lower than the memory
161              area that is actually created in the process's  virtual  address
162              space.   Touching  an address in the "guard" page below the map‐
163              ping will cause the mapping to grow by a page.  This growth  can
164              be repeated until the mapping grows to within a page of the high
165              end of the next lower  mapping,  at  which  point  touching  the
166              "guard" page will result in a SIGSEGV signal.
167
168       MAP_HUGETLB (since Linux 2.6.32)
169              Allocate  the  mapping using "huge pages."  See the Linux kernel
170              source  file  Documentation/admin-guide/mm/hugetlbpage.rst   for
171              further information, as well as NOTES, below.
172
173       MAP_HUGE_2MB, MAP_HUGE_1GB (since Linux 3.8)
174              Used  in  conjunction  with  MAP_HUGETLB  to  select alternative
175              hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that
176              support multiple hugetlb page sizes.
177
178              More  generally, the desired huge page size can be configured by
179              encoding the base-2 logarithm of the desired page  size  in  the
180              six bits at the offset MAP_HUGE_SHIFT.  (A value of zero in this
181              bit field provides the default huge page size; the default  huge
182              page  size  can be discovered via the Hugepagesize field exposed
183              by /proc/meminfo.)  Thus, the above two  constants  are  defined
184              as:
185
186                  #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
187                  #define MAP_HUGE_1GB    (30 << MAP_HUGE_SHIFT)
188
189              The  range  of  huge page sizes that are supported by the system
190              can be discovered by listing  the  subdirectories  in  /sys/ker‐
191              nel/mm/hugepages.
192
193       MAP_LOCKED (since Linux 2.5.37)
194              Mark the mapped region to be locked in the same way as mlock(2).
195              This implementation will try to populate  (prefault)  the  whole
196              range  but  the  mmap()  call  doesn't  fail with ENOMEM if this
197              fails.  Therefore major faults might happen later  on.   So  the
198              semantic  is  not  as strong as mlock(2).  One should use mmap()
199              plus mlock(2) when major faults are  not  acceptable  after  the
200              initialization  of  the mapping.  The MAP_LOCKED flag is ignored
201              in older kernels.
202
203       MAP_NONBLOCK (since Linux 2.5.46)
204              This flag is meaningful only in conjunction  with  MAP_POPULATE.
205              Don't  perform  read-ahead:  create page tables entries only for
206              pages that are already present in RAM.  Since Linux 2.6.23, this
207              flag  causes  MAP_POPULATE to do nothing.  One day, the combina‐
208              tion of MAP_POPULATE and MAP_NONBLOCK may be reimplemented.
209
210       MAP_NORESERVE
211              Do not reserve swap space for this mapping.  When swap space  is
212              reserved,  one  has  the guarantee that it is possible to modify
213              the mapping.  When swap space is  not  reserved  one  might  get
214              SIGSEGV  upon  a  write if no physical memory is available.  See
215              also the discussion of the  file  /proc/sys/vm/overcommit_memory
216              in  proc(5).   In  kernels before 2.6, this flag had effect only
217              for private writable mappings.
218
219       MAP_POPULATE (since Linux 2.5.46)
220              Populate (prefault) page tables for a mapping.  For a file  map‐
221              ping,  this  causes  read-ahead  on the file.  This will help to
222              reduce blocking on page faults later.  MAP_POPULATE is supported
223              for private mappings only since Linux 2.6.23.
224
225       MAP_STACK (since Linux 2.6.27)
226              Allocate  the  mapping  at  an address suitable for a process or
227              thread stack.
228
229              This flag is currently a no-op on Linux.  However, by  employing
230              this  flag,  applications  can  ensure  that  they transparently
231              obtain support if the flag is implemented in the future.   Thus,
232              it  is  used  in the glibc threading implementation to allow for
233              the fact that some architectures  may  (later)  require  special
234              treatment  for  stack  allocations.   A further reason to employ
235              this flag is portability: MAP_STACK exists (and has  an  effect)
236              on some other systems (e.g., some of the BSDs).
237
238       MAP_SYNC (since Linux 4.15)
239              This flag is available only with the MAP_SHARED_VALIDATE mapping
240              type; mappings of type  MAP_SHARED  will  silently  ignore  this
241              flag.   This  flag  is  supported  only for files supporting DAX
242              (direct mapping of persistent memory).  For other files,  creat‐
243              ing a mapping with this flag results in an EOPNOTSUPP error.
244
245              Shared  file  mappings with this flag provide the guarantee that
246              while some memory is writably mapped in the address space of the
247              process,  it will be visible in the same file at the same offset
248              even after the system crashes or is  rebooted.   In  conjunction
249              with  the  use  of  appropriate  CPU instructions, this provides
250              users of such mappings with a more efficient way of making  data
251              modifications persistent.
252
253       MAP_UNINITIALIZED (since Linux 2.6.33)
254              Don't  clear  anonymous pages.  This flag is intended to improve
255              performance on embedded devices.  This flag is honored  only  if
256              the  kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIAL‐
257              IZED option.  Because of the security implications, that  option
258              is  normally  enabled  only  on  embedded devices (i.e., devices
259              where one has complete control of the contents of user memory).
260
261       Of the above flags, only MAP_FIXED is  specified  in  POSIX.1-2001  and
262       POSIX.1-2008.  However, most systems also support MAP_ANONYMOUS (or its
263       synonym MAP_ANON).
264
265       Memory mapped by mmap() is preserved  across  fork(2),  with  the  same
266       attributes.
267
268       A file is mapped in multiples of the page size.  For a file that is not
269       a multiple of the page  size,  the  remaining  memory  is  zeroed  when
270       mapped, and writes to that region are not written out to the file.  The
271       effect of changing the size of the underlying file of a mapping on  the
272       pages  that  correspond  to  added  or  removed  regions of the file is
273       unspecified.
274
275   munmap()
276       The munmap() system call deletes the mappings for the specified address
277       range,  and  causes further references to addresses within the range to
278       generate invalid memory references.  The region is  also  automatically
279       unmapped  when  the  process is terminated.  On the other hand, closing
280       the file descriptor does not unmap the region.
281
282       The address addr must be a multiple of the page size (but  length  need
283       not  be).   All  pages  containing  a  part  of the indicated range are
284       unmapped, and  subsequent  references  to  these  pages  will  generate
285       SIGSEGV.   It  is  not an error if the indicated range does not contain
286       any mapped pages.
287

RETURN VALUE

289       On success, mmap() returns a pointer to the mapped area.  On error, the
290       value  MAP_FAILED  (that is, (void *) -1) is returned, and errno is set
291       to indicate the cause of the error.
292
293       On success, munmap() returns 0.  On failure, it returns -1,  and  errno
294       is set to indicate the cause of the error (probably to EINVAL).
295

ERRORS

297       EACCES A  file descriptor refers to a non-regular file.  Or a file map‐
298              ping was  requested,  but  fd  is  not  open  for  reading.   Or
299              MAP_SHARED  was  requested  and PROT_WRITE is set, but fd is not
300              open in read/write (O_RDWR) mode.  Or PROT_WRITE is set, but the
301              file is append-only.
302
303       EAGAIN The  file  has  been  locked, or too much memory has been locked
304              (see setrlimit(2)).
305
306       EBADF  fd is not a valid file descriptor  (and  MAP_ANONYMOUS  was  not
307              set).
308
309       EEXIST MAP_FIXED_NOREPLACE  was  specified in flags, and the range cov‐
310              ered by addr and length clashes with an existing mapping.
311
312       EINVAL We don't like addr, length, or offset (e.g., they are too large,
313              or not aligned on a page boundary).
314
315       EINVAL (since Linux 2.6.12) length was 0.
316
317       EINVAL flags    contained    none   of   MAP_PRIVATE,   MAP_SHARED   or
318              MAP_SHARED_VALIDATE.
319
320       ENFILE The system-wide limit on the total number of open files has been
321              reached.
322
323       ENODEV The underlying filesystem of the specified file does not support
324              memory mapping.
325
326       ENOMEM No memory is available.
327
328       ENOMEM The  process's  maximum  number  of  mappings  would  have  been
329              exceeded.   This  error can also occur for munmap(), when unmap‐
330              ping a region in the middle of an existing mapping,  since  this
331              results  in  two  smaller  mappings on either side of the region
332              being unmapped.
333
334       ENOMEM (since Linux 4.7) The process's RLIMIT_DATA limit, described  in
335              getrlimit(2), would have been exceeded.
336
337       EOVERFLOW
338              On  32-bit  architecture  together with the large file extension
339              (i.e., using 64-bit off_t): the number of pages used for  length
340              plus  number  of  pages  used for offset would overflow unsigned
341              long (32 bits).
342
343       EPERM  The prot argument asks for PROT_EXEC but the mapped area belongs
344              to a file on a filesystem that was mounted no-exec.
345
346       EPERM  The operation was prevented by a file seal; see fcntl(2).
347
348       ETXTBSY
349              MAP_DENYWRITE was set but the object specified by fd is open for
350              writing.
351
352       Use of a mapped region can result in these signals:
353
354       SIGSEGV
355              Attempted write into a region mapped as read-only.
356
357       SIGBUS Attempted access to a portion of the buffer that does not corre‐
358              spond  to  the  file  (for  example, beyond the end of the file,
359              including the case  where  another  process  has  truncated  the
360              file).
361

ATTRIBUTES

363       For   an   explanation   of   the  terms  used  in  this  section,  see
364       attributes(7).
365
366       ┌───────────────────┬───────────────┬─────────┐
367Interface          Attribute     Value   
368       ├───────────────────┼───────────────┼─────────┤
369mmap(), munmap()   │ Thread safety │ MT-Safe │
370       └───────────────────┴───────────────┴─────────┘

CONFORMING TO

372       POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD.
373

AVAILABILITY

375       On POSIX systems on which mmap(), msync(2), and munmap() are available,
376       _POSIX_MAPPED_FILES is defined in <unistd.h> to a value greater than 0.
377       (See also sysconf(3).)
378

NOTES

380       On  some  hardware  architectures  (e.g.,  i386),  PROT_WRITE   implies
381       PROT_READ.   It  is  architecture  dependent  whether PROT_READ implies
382       PROT_EXEC or not.  Portable programs should  always  set  PROT_EXEC  if
383       they intend to execute code in the new mapping.
384
385       The  portable  way  to create a mapping is to specify addr as 0 (NULL),
386       and omit MAP_FIXED from flags.  In this case, the  system  chooses  the
387       address  for  the  mapping; the address is chosen so as not to conflict
388       with any existing mapping, and will not be 0.  If the MAP_FIXED flag is
389       specified,  and  addr  is  0  (NULL), then the mapped address will be 0
390       (NULL).
391
392       Certain flags constants are  defined  only  if  suitable  feature  test
393       macros  are  defined  (possibly by default): _DEFAULT_SOURCE with glibc
394       2.19 or later; or _BSD_SOURCE or _SVID_SOURCE in glibc  2.19  and  ear‐
395       lier.   (Employing  _GNU_SOURCE also suffices, and requiring that macro
396       specifically would have been more logical, since these  flags  are  all
397       Linux-specific.)  The relevant flags are: MAP_32BIT, MAP_ANONYMOUS (and
398       the  synonym  MAP_ANON),   MAP_DENYWRITE,   MAP_EXECUTABLE,   MAP_FILE,
399       MAP_GROWSDOWN,  MAP_HUGETLB,  MAP_LOCKED,  MAP_NONBLOCK, MAP_NORESERVE,
400       MAP_POPULATE, and MAP_STACK.
401
402       An application can determine which pages of  a  mapping  are  currently
403       resident in the buffer/page cache using mincore(2).
404
405   Using MAP_FIXED safely
406       The only safe use for MAP_FIXED is where the address range specified by
407       addr and length was previously reserved using another  mapping;  other‐
408       wise,  the  use  of  MAP_FIXED is hazardous because it forcibly removes
409       preexisting mappings, making it easy for  a  multithreaded  process  to
410       corrupt its own address space.
411
412       For  example,  suppose that thread A looks through /proc/<pid>/maps and
413       in order to locate an unused  address  range  that  it  can  map  using
414       MAP_FIXED,  while  thread B simultaneously acquires part or all of that
415       same   address   range.    When   thread   A    subsequently    employs
416       mmap(MAP_FIXED),  it will effectively clobber the mapping that thread B
417       created.  In  this  scenario,  thread  B  need  not  create  a  mapping
418       directly; simply making a library call that, internally, uses dlopen(3)
419       to load some other shared library, will suffice.   The  dlopen(3)  call
420       will  map  the  library into the process's address space.  Furthermore,
421       almost any library call may be implemented in a way  that  adds  memory
422       mappings to the address space, either with this technique, or by simply
423       allocating memory.  Examples include  brk(2),  malloc(3),  pthread_cre‐
424       ate(3), and the PAM libraries ⟨http://www.linux-pam.org⟩.
425
426       Since  Linux  4.17, a multithreaded program can use the MAP_FIXED_NORE‐
427       PLACE flag to avoid the hazard described above when attempting to  cre‐
428       ate a mapping at a fixed address that has not been reserved by a preex‐
429       isting mapping.
430
431   Timestamps changes for file-backed mappings
432       For file-backed mappings, the st_atime field for the mapped file may be
433       updated at any time between the mmap() and the corresponding unmapping;
434       the first reference to a mapped page will update the field  if  it  has
435       not been already.
436
437       The  st_ctime  and st_mtime field for a file mapped with PROT_WRITE and
438       MAP_SHARED will be updated after a write  to  the  mapped  region,  and
439       before  a subsequent msync(2) with the MS_SYNC or MS_ASYNC flag, if one
440       occurs.
441
442   Huge page (Huge TLB) mappings
443       For mappings that employ huge pages, the requirements for the arguments
444       of  mmap()  and munmap() differ somewhat from the requirements for map‐
445       pings that use the native system page size.
446
447       For mmap(), offset must be a multiple of the underlying huge page size.
448       The system automatically aligns length to be a multiple of the underly‐
449       ing huge page size.
450
451       For munmap(), addr and length must both be a multiple of the underlying
452       huge page size.
453
454   C library/kernel differences
455       This  page describes the interface provided by the glibc mmap() wrapper
456       function.  Originally, this function invoked a system call of the  same
457       name.   Since  kernel  2.4,  that  system  call  has been superseded by
458       mmap2(2), and  nowadays  the  glibc  mmap()  wrapper  function  invokes
459       mmap2(2) with a suitably adjusted value for offset.
460

BUGS

462       On  Linux,  there  are  no  guarantees like those suggested above under
463       MAP_NORESERVE.  By default, any process can be  killed  at  any  moment
464       when the system runs out of memory.
465
466       In  kernels before 2.6.7, the MAP_POPULATE flag has effect only if prot
467       is specified as PROT_NONE.
468
469       SUSv3 specifies that mmap() should fail if length is  0.   However,  in
470       kernels  before  2.6.12,  mmap() succeeded in this case: no mapping was
471       created and the call returned addr.  Since kernel 2.6.12, mmap()  fails
472       with the error EINVAL for this case.
473
474       POSIX specifies that the system shall always zero fill any partial page
475       at the end of the object and that system will never write any modifica‐
476       tion  of  the  object beyond its end.  On Linux, when you write data to
477       such partial page after the end of the object, the data  stays  in  the
478       page  cache  even after the file is closed and unmapped and even though
479       the data is never written to the file itself, subsequent  mappings  may
480       see  the modified content.  In some cases, this could be fixed by call‐
481       ing msync(2) before the unmap takes place; however, this  doesn't  work
482       on  tmpfs(5) (for example, when using the POSIX shared memory interface
483       documented in shm_overview(7)).
484

EXAMPLE

486       The following program prints part of the file specified  in  its  first
487       command-line  argument  to  standard  output.  The range of bytes to be
488       printed is specified via offset and length values  in  the  second  and
489       third  command-line arguments.  The program creates a memory mapping of
490       the required pages of the file and then uses  write(2)  to  output  the
491       desired bytes.
492
493   Program source
494       #include <sys/mman.h>
495       #include <sys/stat.h>
496       #include <fcntl.h>
497       #include <stdio.h>
498       #include <stdlib.h>
499       #include <unistd.h>
500
501       #define handle_error(msg) \
502           do { perror(msg); exit(EXIT_FAILURE); } while (0)
503
504       int
505       main(int argc, char *argv[])
506       {
507           char *addr;
508           int fd;
509           struct stat sb;
510           off_t offset, pa_offset;
511           size_t length;
512           ssize_t s;
513
514           if (argc < 3 || argc > 4) {
515               fprintf(stderr, "%s file offset [length]\n", argv[0]);
516               exit(EXIT_FAILURE);
517           }
518
519           fd = open(argv[1], O_RDONLY);
520           if (fd == -1)
521               handle_error("open");
522
523           if (fstat(fd, &sb) == -1)           /* To obtain file size */
524               handle_error("fstat");
525
526           offset = atoi(argv[2]);
527           pa_offset = offset & ~(sysconf(_SC_PAGE_SIZE) - 1);
528               /* offset for mmap() must be page aligned */
529
530           if (offset >= sb.st_size) {
531               fprintf(stderr, "offset is past end of file\n");
532               exit(EXIT_FAILURE);
533           }
534
535           if (argc == 4) {
536               length = atoi(argv[3]);
537               if (offset + length > sb.st_size)
538                   length = sb.st_size - offset;
539                       /* Can't display bytes past end of file */
540
541           } else {    /* No length arg ==> display to end of file */
542               length = sb.st_size - offset;
543           }
544
545           addr = mmap(NULL, length + offset - pa_offset, PROT_READ,
546                       MAP_PRIVATE, fd, pa_offset);
547           if (addr == MAP_FAILED)
548               handle_error("mmap");
549
550           s = write(STDOUT_FILENO, addr + offset - pa_offset, length);
551           if (s != length) {
552               if (s == -1)
553                   handle_error("write");
554
555               fprintf(stderr, "partial write");
556               exit(EXIT_FAILURE);
557           }
558
559           munmap(addr, length + offset - pa_offset);
560           close(fd);
561
562           exit(EXIT_SUCCESS);
563       }
564

SEE ALSO

566       ftruncate(2),  getpagesize(2),  memfd_create(2),  mincore(2), mlock(2),
567       mmap2(2), mprotect(2), mremap(2), msync(2), remap_file_pages(2),  setr‐
568       limit(2), shmat(2), userfaultfd(2), shm_open(3), shm_overview(7)
569
570       The  descriptions  of the following files in proc(5): /proc/[pid]/maps,
571       /proc/[pid]/map_files, and /proc/[pid]/smaps.
572
573       B.O. Gallmeister, POSIX.4, O'Reilly, pp. 128–129 and 389–391.
574

COLOPHON

576       This page is part of release 5.04 of the Linux  man-pages  project.   A
577       description  of  the project, information about reporting bugs, and the
578       latest    version    of    this    page,    can     be     found     at
579       https://www.kernel.org/doc/man-pages/.
580
581
582
583Linux                             2019-10-10                           MMAP(2)
Impressum