]> git.ipfire.org Git - thirdparty/man-pages.git/blame_incremental - man2/mmap.2
socket.2: tfix
[thirdparty/man-pages.git] / man2 / mmap.2
... / ...
CommitLineData
1.\" Copyright (C) 1996 Andries Brouwer <aeb@cwi.nl>
2.\" and Copyright (C) 2006, 2007 Michael Kerrisk <mtk.manpages@gmail.com>
3.\"
4.\" %%%LICENSE_START(VERBATIM)
5.\" Permission is granted to make and distribute verbatim copies of this
6.\" manual provided the copyright notice and this permission notice are
7.\" preserved on all copies.
8.\"
9.\" Permission is granted to copy and distribute modified versions of this
10.\" manual under the conditions for verbatim copying, provided that the
11.\" entire resulting derived work is distributed under the terms of a
12.\" permission notice identical to this one.
13.\"
14.\" Since the Linux kernel and libraries are constantly changing, this
15.\" manual page may be incorrect or out-of-date. The author(s) assume no
16.\" responsibility for errors or omissions, or for damages resulting from
17.\" the use of the information contained herein. The author(s) may not
18.\" have taken the same level of care in the production of this manual,
19.\" which is licensed free of charge, as they might when working
20.\" professionally.
21.\"
22.\" Formatted or processed versions of this manual, if unaccompanied by
23.\" the source, must acknowledge the copyright and authors of this work.
24.\" %%%LICENSE_END
25.\"
26.\" Modified 1997-01-31 by Eric S. Raymond <esr@thyrsus.com>
27.\" Modified 2000-03-25 by Jim Van Zandt <jrv@vanzandt.mv.com>
28.\" Modified 2001-10-04 by John Levon <moz@compsoc.man.ac.uk>
29.\" Modified 2003-02-02 by Andi Kleen <ak@muc.de>
30.\" Modified 2003-05-21 by Michael Kerrisk <mtk.manpages@gmail.com>
31.\" MAP_LOCKED works from 2.5.37
32.\" Modified 2004-06-17 by Michael Kerrisk <mtk.manpages@gmail.com>
33.\" Modified 2004-09-11 by aeb
34.\" Modified 2004-12-08, from Eric Estievenart <eric.estievenart@free.fr>
35.\" Modified 2004-12-08, mtk, formatting tidy-ups
36.\" Modified 2006-12-04, mtk, various parts rewritten
37.\" 2007-07-10, mtk, Added an example program.
38.\" 2008-11-18, mtk, document MAP_STACK
39.\"
40.TH MMAP 2 2018-04-30 "Linux" "Linux Programmer's Manual"
41.SH NAME
42mmap, munmap \- map or unmap files or devices into memory
43.SH SYNOPSIS
44.nf
45.B #include <sys/mman.h>
46.PP
47.BI "void *mmap(void *" addr ", size_t " length \
48", int " prot ", int " flags ,
49.BI " int " fd ", off_t " offset );
50.BI "int munmap(void *" addr ", size_t " length );
51.fi
52.PP
53See NOTES for information on feature test macro requirements.
54.SH DESCRIPTION
55.BR mmap ()
56creates a new mapping in the virtual address space of
57the calling process.
58The starting address for the new mapping is specified in
59.IR addr .
60The
61.I length
62argument specifies the length of the mapping (which must be greater than 0).
63.PP
64If
65.I addr
66is NULL,
67then the kernel chooses the (page-aligned) address
68at which to create the mapping;
69this is the most portable method of creating a new mapping.
70If
71.I addr
72is not NULL,
73then the kernel takes it as a hint about where to place the mapping;
74on Linux, the mapping will be created at a nearby page boundary.
75.\" Before Linux 2.6.24, the address was rounded up to the next page
76.\" boundary; since 2.6.24, it is rounded down!
77The address of the new mapping is returned as the result of the call.
78.PP
79The contents of a file mapping (as opposed to an anonymous mapping; see
80.B MAP_ANONYMOUS
81below), are initialized using
82.I length
83bytes starting at offset
84.I offset
85in the file (or other object) referred to by the file descriptor
86.IR fd .
87.I offset
88must be a multiple of the page size as returned by
89.IR sysconf(_SC_PAGE_SIZE) .
90.PP
91After the
92.BR mmap ()
93call has returned, the file descriptor,
94.IR fd ,
95can be closed immediately without invalidating the mapping.
96.PP
97The
98.I prot
99argument describes the desired memory protection of the mapping
100(and must not conflict with the open mode of the file).
101It is either
102.B PROT_NONE
103or the bitwise OR of one or more of the following flags:
104.TP 1.1i
105.B PROT_EXEC
106Pages may be executed.
107.TP
108.B PROT_READ
109Pages may be read.
110.TP
111.B PROT_WRITE
112Pages may be written.
113.TP
114.B PROT_NONE
115Pages may not be accessed.
116.PP
117The
118.I flags
119argument determines whether updates to the mapping
120are visible to other processes mapping the same region,
121and whether updates are carried through to the underlying file.
122This behavior is determined by including exactly one
123of the following values in
124.IR flags :
125.TP
126.B MAP_SHARED
127Share this mapping.
128Updates to the mapping are visible to other processes mapping the same region,
129and (in the case of file-backed mappings)
130are carried through to the underlying file.
131(To precisely control when updates are carried through
132to the underlying file requires the use of
133.BR msync (2).)
134.TP
135.BR MAP_SHARED_VALIDATE " (since Linux 4.15)"
136This flag provides the same behavior as
137.B MAP_SHARED
138except that
139.B MAP_SHARED
140mappings ignore unknown flags in
141.IR flags .
142By contrast, when creating a mapping using
143.BR MAP_SHARED_VALIDATE ,
144the kernel verifies all passed flags are known and fails the
145mapping with the error
146.BR EOPNOTSUPP
147for unknown flags.
148This mapping type is also required to be able to use some mapping flags
149(e.g.,
150.BR MAP_SYNC ).
151.TP
152.B MAP_PRIVATE
153Create a private copy-on-write mapping.
154Updates to the mapping are not visible to other processes
155mapping the same file, and are not carried through to
156the underlying file.
157It is unspecified whether changes made to the file after the
158.BR mmap ()
159call are visible in the mapped region.
160.PP
161Both
162.B MAP_SHARED
163and
164.B MAP_PRIVATE
165are described in POSIX.1-2001 and POSIX.1-2008.
166.B MAP_SHARED_VALIDATE
167is a Linux extension.
168.PP
169In addition, zero or more of the following values can be ORed in
170.IR flags :
171.TP
172.BR MAP_32BIT " (since Linux 2.4.20, 2.6)"
173Put the mapping into the first 2 Gigabytes of the process address space.
174This flag is supported only on x86-64, for 64-bit programs.
175It was added to allow thread stacks to be allocated somewhere
176in the first 2\ GB of memory,
177so as to improve context-switch performance on some early
17864-bit processors.
179.\" See http://lwn.net/Articles/294642 "Tangled up in threads", 19 Aug 08
180Modern x86-64 processors no longer have this performance problem,
181so use of this flag is not required on those systems.
182The
183.B MAP_32BIT
184flag is ignored when
185.B MAP_FIXED
186is set.
187.TP
188.B MAP_ANON
189Synonym for
190.BR MAP_ANONYMOUS .
191Deprecated.
192.TP
193.B MAP_ANONYMOUS
194The mapping is not backed by any file;
195its contents are initialized to zero.
196The
197.I fd
198argument is ignored;
199however, some implementations require
200.I fd
201to be \-1 if
202.B MAP_ANONYMOUS
203(or
204.BR MAP_ANON )
205is specified,
206and portable applications should ensure this.
207The
208.I offset
209argument should be zero.
210.\" See the pgoff overflow check in do_mmap().
211.\" See the offset check in sys_mmap in arch/x86/kernel/sys_x86_64.c.
212The use of
213.B MAP_ANONYMOUS
214in conjunction with
215.B MAP_SHARED
216is supported on Linux only since kernel 2.4.
217.TP
218.B MAP_DENYWRITE
219This flag is ignored.
220.\" Introduced in 1.1.36, removed in 1.3.24.
221(Long ago\(emLinux 2.0 and earlier\(emit signaled
222that attempts to write to the underlying file should fail with
223.BR ETXTBUSY .
224But this was a source of denial-of-service attacks.)
225.TP
226.B MAP_EXECUTABLE
227This flag is ignored.
228.\" Introduced in 1.1.38, removed in 1.3.24. Flag tested in proc_follow_link.
229.\" (Long ago, it signaled that the underlying file is an executable.
230.\" However, that information was not really used anywhere.)
231.\" Linus talked about DOS related to MAP_EXECUTABLE, but he was thinking of
232.\" MAP_DENYWRITE?
233.TP
234.B MAP_FILE
235Compatibility flag.
236Ignored.
237.\" On some systems, this was required as the opposite of
238.\" MAP_ANONYMOUS -- mtk, 1 May 2007
239.TP
240.B MAP_FIXED
241Don't interpret
242.I addr
243as a hint: place the mapping at exactly that address.
244.I addr
245must be suitably aligned: for most architectures a multiple of the page
246size is sufficient; however, some architectures may impose additional
247restrictions.
248If the memory region specified by
249.I addr
250and
251.I len
252overlaps pages of any existing mapping(s), then the overlapped
253part of the existing mapping(s) will be discarded.
254If the specified address cannot be used,
255.BR mmap ()
256will fail.
257.IP
258Software that aspires to be portable should use the
259.BR MAP_FIXED
260flag with care,
261keeping in mind that the exact layout of a process's memory mappings
262is allowed to change significantly between kernel versions,
263C library versions, and operating system releases.
264.IR "Carefully read the discussion of this flag in NOTES!"
265.TP
266.BR MAP_FIXED_NOREPLACE " (since Linux 4.17)"
267.\" commit a4ff8e8620d3f4f50ac4b41e8067b7d395056843
268This flag provides behavior that is similar to
269.B MAP_FIXED
270with respect to the
271.I addr
272enforcement, but differs in that
273.B MAP_FIXED_NOREPLACE
274never clobbers a preexisting mapped range.
275If the requested range would collide with an existing mapping,
276then this call fails with the error
277.B EEXIST.
278This flag can therefore be used as a way to atomically
279(with respect to other threads) attempt to map an address range:
280one thread will succeed; all others will report failure.
281.IP
282Note that older kernels which do not recognize the
283.BR MAP_FIXED_NOREPLACE
284flag will typically (upon detecting a collision with a preexisting mapping)
285fall back to a "non-\c
286.B MAP_FIXED\c
287" type of behavior:
288they will return an address that is different from the requested address.
289Therefore, backward-compatible software
290should check the returned address against the requested address.
291.TP
292.B MAP_GROWSDOWN
293This flag is used for stacks.
294It indicates to the kernel virtual memory system that the mapping
295should extend downward in memory.
296The return address is one page lower than the memory area that is
297actually created in the process's virtual address space.
298Touching an address in the "guard" page below the mapping will cause
299the mapping to grow by a page.
300This growth can be repeated until the mapping grows to within a
301page of the high end of the next lower mapping,
302at which point touching the "guard" page will result in a
303.B SIGSEGV
304signal.
305.TP
306.BR MAP_HUGETLB " (since Linux 2.6.32)"
307Allocate the mapping using "huge pages."
308See the Linux kernel source file
309.I Documentation/admin-guide/mm/hugetlbpage.rst
310for further information, as well as NOTES, below.
311.TP
312.BR MAP_HUGE_2MB ", " MAP_HUGE_1GB " (since Linux 3.8)"
313.\" See https://lwn.net/Articles/533499/
314Used in conjunction with
315.B MAP_HUGETLB
316to select alternative hugetlb page sizes (respectively, 2\ MB and 1\ GB)
317on systems that support multiple hugetlb page sizes.
318.IP
319More generally, the desired huge page size can be configured by encoding
320the base-2 logarithm of the desired page size in the six bits at the offset
321.BR MAP_HUGE_SHIFT .
322(A value of zero in this bit field provides the default huge page size;
323the default huge page size can be discovered via the
324.I Hugepagesize
325field exposed by
326.IR /proc/meminfo .)
327Thus, the above two constants are defined as:
328.IP
329.in +4n
330.EX
331#define MAP_HUGE_2MB (21 << MAP_HUGE_SHIFT)
332#define MAP_HUGE_1GB (30 << MAP_HUGE_SHIFT)
333.EE
334.in
335.IP
336The range of huge page sizes that are supported by the system
337can be discovered by listing the subdirectories in
338.IR /sys/kernel/mm/hugepages .
339.TP
340.BR MAP_LOCKED " (since Linux 2.5.37)"
341Mark the mapped region to be locked in the same way as
342.BR mlock (2).
343This implementation will try to populate (prefault) the whole range but the
344.BR mmap ()
345call doesn't fail with
346.B ENOMEM
347if this fails.
348Therefore major faults might happen later on.
349So the semantic is not as strong as
350.BR mlock (2).
351One should use
352.BR mmap ()
353plus
354.BR mlock (2)
355when major faults are not acceptable after the initialization of the mapping.
356The
357.BR MAP_LOCKED
358flag is ignored in older kernels.
359.\" If set, the mapped pages will not be swapped out.
360.TP
361.BR MAP_NONBLOCK " (since Linux 2.5.46)"
362This flag is meaningful only in conjunction with
363.BR MAP_POPULATE .
364Don't perform read-ahead:
365create page tables entries only for pages
366that are already present in RAM.
367Since Linux 2.6.23, this flag causes
368.BR MAP_POPULATE
369to do nothing.
370One day, the combination of
371.BR MAP_POPULATE
372and
373.BR MAP_NONBLOCK
374may be reimplemented.
375.TP
376.B MAP_NORESERVE
377Do not reserve swap space for this mapping.
378When swap space is reserved, one has the guarantee
379that it is possible to modify the mapping.
380When swap space is not reserved one might get
381.B SIGSEGV
382upon a write
383if no physical memory is available.
384See also the discussion of the file
385.I /proc/sys/vm/overcommit_memory
386in
387.BR proc (5).
388In kernels before 2.6, this flag had effect only for
389private writable mappings.
390.TP
391.BR MAP_POPULATE " (since Linux 2.5.46)"
392Populate (prefault) page tables for a mapping.
393For a file mapping, this causes read-ahead on the file.
394This will help to reduce blocking on page faults later.
395.BR MAP_POPULATE
396is supported for private mappings only since Linux 2.6.23.
397.TP
398.BR MAP_STACK " (since Linux 2.6.27)"
399Allocate the mapping at an address suitable for a process
400or thread stack.
401This flag is currently a no-op,
402but is used in the glibc threading implementation so that
403if some architectures require special treatment for stack allocations,
404support can later be transparently implemented for glibc.
405.\" See http://lwn.net/Articles/294642 "Tangled up in threads", 19 Aug 08
406.\" commit cd98a04a59e2f94fa64d5bf1e26498d27427d5e7
407.\" http://thread.gmane.org/gmane.linux.kernel/720412
408.\" "pthread_create() slow for many threads; also time to revisit 64b
409.\" context switch optimization?"
410.TP
411.BR MAP_SYNC " (since Linux 4.15)"
412This flag is available only with the
413.B MAP_SHARED_VALIDATE
414mapping type;
415mappings of type
416.B MAP_SHARED
417will silently ignore this flag.
418This flag is supported only for files supporting DAX
419(direct mapping of persistent memory).
420For other files, creating a mapping with this flag results in an
421.B EOPNOTSUPP
422error.
423.IP
424Shared file mappings with this flag provide the guarantee that while
425some memory is writably mapped in the address space of the process,
426it will be visible in the same file at the same offset even after
427the system crashes or is rebooted.
428In conjunction with the use of appropriate CPU instructions,
429this provides users of such mappings with a more efficient way
430of making data modifications persistent.
431.TP
432.BR MAP_UNINITIALIZED " (since Linux 2.6.33)"
433Don't clear anonymous pages.
434This flag is intended to improve performance on embedded devices.
435This flag is honored only if the kernel was configured with the
436.B CONFIG_MMAP_ALLOW_UNINITIALIZED
437option.
438Because of the security implications,
439that option is normally enabled only on embedded devices
440(i.e., devices where one has complete control of the contents of user memory).
441.PP
442Of the above flags, only
443.B MAP_FIXED
444is specified in POSIX.1-2001 and POSIX.1-2008.
445However, most systems also support
446.B MAP_ANONYMOUS
447(or its synonym
448.BR MAP_ANON ).
449.\" FIXME . for later review when Issue 8 is one day released...
450.\" POSIX may add MAP_ANON in the future
451.\" http://austingroupbugs.net/tag_view_page.php?tag_id=8
452.\" http://austingroupbugs.net/view.php?id=850
453.PP
454Memory mapped by
455.BR mmap ()
456is preserved across
457.BR fork (2),
458with the same attributes.
459.PP
460A file is mapped in multiples of the page size.
461For a file that is not
462a multiple of the page size, the remaining memory is zeroed when mapped,
463and writes to that region are not written out to the file.
464The effect of
465changing the size of the underlying file of a mapping on the pages that
466correspond to added or removed regions of the file is unspecified.
467.SS munmap()
468The
469.BR munmap ()
470system call deletes the mappings for the specified address range, and
471causes further references to addresses within the range to generate
472invalid memory references.
473The region is also automatically unmapped
474when the process is terminated.
475On the other hand, closing the file
476descriptor does not unmap the region.
477.PP
478The address
479.I addr
480must be a multiple of the page size (but
481.I length
482need not be).
483All pages containing a part
484of the indicated range are unmapped, and subsequent references
485to these pages will generate
486.BR SIGSEGV .
487It is not an error if the
488indicated range does not contain any mapped pages.
489.SH RETURN VALUE
490On success,
491.BR mmap ()
492returns a pointer to the mapped area.
493On error, the value
494.B MAP_FAILED
495(that is,
496.IR "(void\ *)\ \-1" )
497is returned, and
498.I errno
499is set to indicate the cause of the error.
500.PP
501On success,
502.BR munmap ()
503returns 0.
504On failure, it returns \-1, and
505.I errno
506is set to indicate the cause of the error (probably to
507.BR EINVAL ).
508.SH ERRORS
509.TP
510.B EACCES
511A file descriptor refers to a non-regular file.
512Or a file mapping was requested, but
513.I fd
514is not open for reading.
515Or
516.B MAP_SHARED
517was requested and
518.B PROT_WRITE
519is set, but
520.I fd
521is not open in read/write
522.RB ( O_RDWR )
523mode.
524Or
525.B PROT_WRITE
526is set, but the file is append-only.
527.TP
528.B EAGAIN
529The file has been locked, or too much memory has been locked (see
530.BR setrlimit (2)).
531.TP
532.B EBADF
533.I fd
534is not a valid file descriptor (and
535.B MAP_ANONYMOUS
536was not set).
537.TP
538.B EEXIST
539.BR MAP_FIXED_NOREPLACE
540was specified in
541.IR flags ,
542and the range covered by
543.IR addr
544and
545.IR length
546clashes with an existing mapping.
547.TP
548.B EINVAL
549We don't like
550.IR addr ,
551.IR length ,
552or
553.I offset
554(e.g., they are too large, or not aligned on a page boundary).
555.TP
556.B EINVAL
557(since Linux 2.6.12)
558.I length
559was 0.
560.TP
561.B EINVAL
562.I flags
563contained neither
564.B MAP_PRIVATE
565or
566.BR MAP_SHARED ,
567or contained both of these values.
568.TP
569.B ENFILE
570.\" This is for shared anonymous segments
571.\" [2.6.7] shmem_zero_setup()-->shmem_file_setup()-->get_empty_filp()
572The system-wide limit on the total number of open files has been reached.
573.\" .TP
574.\" .B ENOEXEC
575.\" A file could not be mapped for reading.
576.TP
577.B ENODEV
578The underlying filesystem of the specified file does not support
579memory mapping.
580.TP
581.B ENOMEM
582No memory is available.
583.TP
584.B ENOMEM
585The process's maximum number of mappings would have been exceeded.
586This error can also occur for
587.BR munmap (),
588when unmapping a region in the middle of an existing mapping,
589since this results in two smaller mappings on either side of
590the region being unmapped.
591.TP
592.B ENOMEM
593(since Linux 4.7)
594The process's
595.B RLIMIT_DATA
596limit, described in
597.BR getrlimit (2),
598would have been exceeded.
599.TP
600.B EOVERFLOW
601On 32-bit architecture together with the large file extension
602(i.e., using 64-bit
603.IR off_t ):
604the number of pages used for
605.I length
606plus number of pages used for
607.I offset
608would overflow
609.I "unsigned long"
610(32 bits).
611.TP
612.B EPERM
613The
614.I prot
615argument asks for
616.B PROT_EXEC
617but the mapped area belongs to a file on a filesystem that
618was mounted no-exec.
619.\" (Since 2.4.25 / 2.6.0.)
620.TP
621.B EPERM
622The operation was prevented by a file seal; see
623.BR fcntl (2).
624.TP
625.B ETXTBSY
626.B MAP_DENYWRITE
627was set but the object specified by
628.I fd
629is open for writing.
630.PP
631Use of a mapped region can result in these signals:
632.TP
633.B SIGSEGV
634Attempted write into a region mapped as read-only.
635.TP
636.B SIGBUS
637Attempted access to a portion of the buffer that does not correspond
638to the file (for example, beyond the end of the file, including the
639case where another process has truncated the file).
640.SH ATTRIBUTES
641For an explanation of the terms used in this section, see
642.BR attributes (7).
643.TS
644allbox;
645lbw18 lb lb
646l l l.
647Interface Attribute Value
648T{
649.BR mmap (),
650.BR munmap ()
651T} Thread safety MT-Safe
652.TE
653.SH CONFORMING TO
654POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD.
655.\" SVr4 documents additional error codes ENXIO and ENODEV.
656.\" SUSv2 documents additional error codes EMFILE and EOVERFLOW.
657.SH AVAILABILITY
658On POSIX systems on which
659.BR mmap (),
660.BR msync (2),
661and
662.BR munmap ()
663are available,
664.B _POSIX_MAPPED_FILES
665is defined in \fI<unistd.h>\fP to a value greater than 0.
666(See also
667.BR sysconf (3).)
668.\" POSIX.1-2001: It shall be defined to -1 or 0 or 200112L.
669.\" -1: unavailable, 0: ask using sysconf().
670.\" glibc defines it to 1.
671.SH NOTES
672On some hardware architectures (e.g., i386),
673.B PROT_WRITE
674implies
675.BR PROT_READ .
676It is architecture dependent whether
677.B PROT_READ
678implies
679.B PROT_EXEC
680or not.
681Portable programs should always set
682.B PROT_EXEC
683if they intend to execute code in the new mapping.
684.PP
685The portable way to create a mapping is to specify
686.I addr
687as 0 (NULL), and omit
688.B MAP_FIXED
689from
690.IR flags .
691In this case, the system chooses the address for the mapping;
692the address is chosen so as not to conflict with any existing mapping,
693and will not be 0.
694If the
695.B MAP_FIXED
696flag is specified, and
697.I addr
698is 0 (NULL), then the mapped address will be 0 (NULL).
699.PP
700Certain
701.I flags
702constants are defined only if suitable feature test macros are defined
703(possibly by default):
704.BR _DEFAULT_SOURCE
705with glibc 2.19 or later;
706or
707.BR _BSD_SOURCE
708or
709.BR _SVID_SOURCE
710in glibc 2.19 and earlier.
711(Employing
712.BR _GNU_SOURCE
713also suffices,
714and requiring that macro specifically would have been more logical,
715since these flags are all Linux-specific.)
716The relevant flags are:
717.BR MAP_32BIT ,
718.BR MAP_ANONYMOUS
719(and the synonym
720.BR MAP_ANON ),
721.BR MAP_DENYWRITE ,
722.BR MAP_EXECUTABLE ,
723.BR MAP_FILE ,
724.BR MAP_GROWSDOWN ,
725.BR MAP_HUGETLB ,
726.BR MAP_LOCKED ,
727.BR MAP_NONBLOCK ,
728.BR MAP_NORESERVE ,
729.BR MAP_POPULATE ,
730and
731.BR MAP_STACK .
732.PP
733An application can determine which pages of a mapping are
734currently resident in the buffer/page cache using
735.BR mincore (2).
736.\"
737.SS Using MAP_FIXED safely
738The only safe use for
739.BR MAP_FIXED
740is where the address range specified by
741.IR addr
742and
743.I length
744was previously reserved using another mapping;
745otherwise, the use of
746.BR MAP_FIXED
747is hazardous because it forcibly removes preexisting mappings,
748making it easy for a multithreaded process to corrupt its own address space.
749.PP
750For example, suppose that thread A looks through
751.I /proc/<pid>/maps
752and in order to locate an unused address range that it can map using
753.BR MAP_FIXED ,
754while thread B simultaneously acquires part or all of that same
755address range.
756When thread A subsequently employs
757.BR mmap(MAP_FIXED) ,
758it will effectively clobber the mapping that thread B created.
759In this scenario,
760thread B need not create a mapping directly; simply making a library call
761that, internally, uses
762.BR dlopen (3)
763to load some other shared library, will suffice.
764The
765.BR dlopen (3)
766call will map the library into the process's address space.
767Furthermore, almost any library call may be implemented in a way that
768adds memory mappings to the address space, either with this technique,
769or by simply allocating memory.
770Examples include
771.BR brk (2),
772.BR malloc (3),
773.BR pthread_create (3),
774and the PAM libraries
775.UR http://www.linux-pam.org
776.UE .
777.PP
778Since Linux 4.17, a multithreaded program can use the
779.BR MAP_FIXED_NOREPLACE
780flag to avoid the hazard described above
781when attempting to create a mapping at a fixed address
782that has not been reserved by a preexisting mapping.
783.\"
784.SS Timestamps changes for file-backed mappings
785For file-backed mappings, the
786.I st_atime
787field for the mapped file may be updated at any time between the
788.BR mmap ()
789and the corresponding unmapping; the first reference to a mapped
790page will update the field if it has not been already.
791.PP
792The
793.I st_ctime
794and
795.I st_mtime
796field for a file mapped with
797.B PROT_WRITE
798and
799.B MAP_SHARED
800will be updated after
801a write to the mapped region, and before a subsequent
802.BR msync (2)
803with the
804.B MS_SYNC
805or
806.B MS_ASYNC
807flag, if one occurs.
808.\"
809.SS Huge page (Huge TLB) mappings
810For mappings that employ huge pages, the requirements for the arguments of
811.BR mmap ()
812and
813.BR munmap ()
814differ somewhat from the requirements for mappings
815that use the native system page size.
816.PP
817For
818.BR mmap (),
819.I offset
820must be a multiple of the underlying huge page size.
821The system automatically aligns
822.I length
823to be a multiple of the underlying huge page size.
824.PP
825For
826.BR munmap (),
827.I addr
828and
829.I length
830must both be a multiple of the underlying huge page size.
831.\"
832.SS C library/kernel differences
833This page describes the interface provided by the glibc
834.BR mmap ()
835wrapper function.
836Originally, this function invoked a system call of the same name.
837Since kernel 2.4, that system call has been superseded by
838.BR mmap2 (2),
839and nowadays
840.\" Since around glibc 2.1/2.2, depending on the platform.
841the glibc
842.BR mmap ()
843wrapper function invokes
844.BR mmap2 (2)
845with a suitably adjusted value for
846.IR offset .
847.SH BUGS
848On Linux, there are no guarantees like those suggested above under
849.BR MAP_NORESERVE .
850By default, any process can be killed
851at any moment when the system runs out of memory.
852.PP
853In kernels before 2.6.7, the
854.B MAP_POPULATE
855flag has effect only if
856.I prot
857is specified as
858.BR PROT_NONE .
859.PP
860SUSv3 specifies that
861.BR mmap ()
862should fail if
863.I length
864is 0.
865However, in kernels before 2.6.12,
866.BR mmap ()
867succeeded in this case: no mapping was created and the call returned
868.IR addr .
869Since kernel 2.6.12,
870.BR mmap ()
871fails with the error
872.B EINVAL
873for this case.
874.PP
875POSIX specifies that the system shall always
876zero fill any partial page at the end
877of the object and that system will never write any modification of the
878object beyond its end.
879On Linux, when you write data to such partial page after the end
880of the object, the data stays in the page cache even after the file
881is closed and unmapped
882and even though the data is never written to the file itself,
883subsequent mappings may see the modified content.
884In some cases, this could be fixed by calling
885.BR msync (2)
886before the unmap takes place;
887however, this doesn't work on
888.BR tmpfs (5)
889(for example, when using the POSIX shared memory interface documented in
890.BR shm_overview (7)).
891.SH EXAMPLE
892.\" FIXME . Add an example here that uses an anonymous shared region for
893.\" IPC between parent and child.
894.PP
895The following program prints part of the file specified in
896its first command-line argument to standard output.
897The range of bytes to be printed is specified via offset and length
898values in the second and third command-line arguments.
899The program creates a memory mapping of the required
900pages of the file and then uses
901.BR write (2)
902to output the desired bytes.
903.SS Program source
904.EX
905#include <sys/mman.h>
906#include <sys/stat.h>
907#include <fcntl.h>
908#include <stdio.h>
909#include <stdlib.h>
910#include <unistd.h>
911
912#define handle_error(msg) \\
913 do { perror(msg); exit(EXIT_FAILURE); } while (0)
914
915int
916main(int argc, char *argv[])
917{
918 char *addr;
919 int fd;
920 struct stat sb;
921 off_t offset, pa_offset;
922 size_t length;
923 ssize_t s;
924
925 if (argc < 3 || argc > 4) {
926 fprintf(stderr, "%s file offset [length]\\n", argv[0]);
927 exit(EXIT_FAILURE);
928 }
929
930 fd = open(argv[1], O_RDONLY);
931 if (fd == \-1)
932 handle_error("open");
933
934 if (fstat(fd, &sb) == \-1) /* To obtain file size */
935 handle_error("fstat");
936
937 offset = atoi(argv[2]);
938 pa_offset = offset & ~(sysconf(_SC_PAGE_SIZE) \- 1);
939 /* offset for mmap() must be page aligned */
940
941 if (offset >= sb.st_size) {
942 fprintf(stderr, "offset is past end of file\\n");
943 exit(EXIT_FAILURE);
944 }
945
946 if (argc == 4) {
947 length = atoi(argv[3]);
948 if (offset + length > sb.st_size)
949 length = sb.st_size \- offset;
950 /* Can\(aqt display bytes past end of file */
951
952 } else { /* No length arg ==> display to end of file */
953 length = sb.st_size \- offset;
954 }
955
956 addr = mmap(NULL, length + offset \- pa_offset, PROT_READ,
957 MAP_PRIVATE, fd, pa_offset);
958 if (addr == MAP_FAILED)
959 handle_error("mmap");
960
961 s = write(STDOUT_FILENO, addr + offset \- pa_offset, length);
962 if (s != length) {
963 if (s == \-1)
964 handle_error("write");
965
966 fprintf(stderr, "partial write");
967 exit(EXIT_FAILURE);
968 }
969
970 munmap(addr, length + offset \- pa_offset);
971 close(fd);
972
973 exit(EXIT_SUCCESS);
974}
975.EE
976.SH SEE ALSO
977.BR ftruncate (2),
978.BR getpagesize (2),
979.BR memfd_create (2),
980.BR mincore (2),
981.BR mlock (2),
982.BR mmap2 (2),
983.BR mprotect (2),
984.BR mremap (2),
985.BR msync (2),
986.BR remap_file_pages (2),
987.BR setrlimit (2),
988.BR shmat (2),
989.BR userfaultfd (2),
990.BR shm_open (3),
991.BR shm_overview (7)
992.PP
993The descriptions of the following files in
994.BR proc (5):
995.IR /proc/[pid]/maps ,
996.IR /proc/[pid]/map_files ,
997and
998.IR /proc/[pid]/smaps .
999.PP
1000B.O. Gallmeister, POSIX.4, O'Reilly, pp. 128\(en129 and 389\(en391.
1001.\"
1002.\" Repeat after me: private read-only mappings are 100% equivalent to
1003.\" shared read-only mappings. No ifs, buts, or maybes. -- Linus