Documentation/admin-guide/mm/nommu-mmap.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/mm/nommu-mmap.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/mm/nommu-mmap.rst
Extension
.rst
Size
12713 bytes
Lines
284
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

=============================
No-MMU memory mapping support
=============================

The kernel has limited support for memory mapping under no-MMU conditions, such
as are used in uClinux environments. From the userspace point of view, memory
mapping is made use of in conjunction with the mmap() system call, the shmat()
call and the execve() system call. From the kernel's point of view, execve()
mapping is actually performed by the binfmt drivers, which call back into the
mmap() routines to do the actual work.

Memory mapping behaviour also involves the way fork(), vfork(), clone() and
ptrace() work. Under uClinux there is no fork(), and clone() must be supplied
the CLONE_VM flag.

The behaviour is similar between the MMU and no-MMU cases, but not identical;
and it's also much more restricted in the latter case:

 (#) Anonymous mapping, MAP_PRIVATE

	In the MMU case: VM regions backed by arbitrary pages; copy-on-write
	across fork.

	In the no-MMU case: VM regions backed by arbitrary contiguous runs of
	pages.

 (#) Anonymous mapping, MAP_SHARED

	These behave very much like private mappings, except that they're
	shared across fork() or clone() without CLONE_VM in the MMU case. Since
	the no-MMU case doesn't support these, behaviour is identical to
	MAP_PRIVATE there.

 (#) File, MAP_PRIVATE, PROT_READ / PROT_EXEC, !PROT_WRITE

	In the MMU case: VM regions backed by pages read from file; changes to
	the underlying file are reflected in the mapping; copied across fork.

	In the no-MMU case:

         - If one exists, the kernel will reuse an existing mapping to the
           same segment of the same file if that has compatible permissions,
           even if this was created by another process.

         - If possible, the file mapping will be directly on the backing device
           if the backing device has the NOMMU_MAP_DIRECT capability and
           appropriate mapping protection capabilities. Ramfs, romfs, cramfs
           and mtd might all permit this.

	 - If the backing device can't or won't permit direct sharing,
           but does have the NOMMU_MAP_COPY capability, then a copy of the
           appropriate bit of the file will be read into a contiguous bit of
           memory and any extraneous space beyond the EOF will be cleared

	 - Writes to the file do not affect the mapping; writes to the mapping
	   are visible in other processes (no MMU protection), but should not
	   happen.

 (#) File, MAP_PRIVATE, PROT_READ / PROT_EXEC, PROT_WRITE

	In the MMU case: like the non-PROT_WRITE case, except that the pages in
	question get copied before the write actually happens. From that point
	on writes to the file underneath that page no longer get reflected into
	the mapping's backing pages. The page is then backed by swap instead.

	In the no-MMU case: works much like the non-PROT_WRITE case, except
	that a copy is always taken and never shared.

 (#) Regular file / blockdev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE

Annotation

Implementation Notes