^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) No-MMU memory mapping support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) The kernel has limited support for memory mapping under no-MMU conditions, such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) as are used in uClinux environments. From the userspace point of view, memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) mapping is made use of in conjunction with the mmap() system call, the shmat()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) call and the execve() system call. From the kernel's point of view, execve()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) mapping is actually performed by the binfmt drivers, which call back into the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) mmap() routines to do the actual work.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) Memory mapping behaviour also involves the way fork(), vfork(), clone() and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) ptrace() work. Under uClinux there is no fork(), and clone() must be supplied
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) the CLONE_VM flag.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) The behaviour is similar between the MMU and no-MMU cases, but not identical;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) and it's also much more restricted in the latter case:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) (#) Anonymous mapping, MAP_PRIVATE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) In the MMU case: VM regions backed by arbitrary pages; copy-on-write
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) across fork.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) In the no-MMU case: VM regions backed by arbitrary contiguous runs of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) pages.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) (#) Anonymous mapping, MAP_SHARED
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) These behave very much like private mappings, except that they're
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) shared across fork() or clone() without CLONE_VM in the MMU case. Since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) the no-MMU case doesn't support these, behaviour is identical to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) MAP_PRIVATE there.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) (#) File, MAP_PRIVATE, PROT_READ / PROT_EXEC, !PROT_WRITE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) In the MMU case: VM regions backed by pages read from file; changes to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) the underlying file are reflected in the mapping; copied across fork.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) In the no-MMU case:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) - If one exists, the kernel will re-use an existing mapping to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) same segment of the same file if that has compatible permissions,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) even if this was created by another process.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) - If possible, the file mapping will be directly on the backing device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) if the backing device has the NOMMU_MAP_DIRECT capability and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) appropriate mapping protection capabilities. Ramfs, romfs, cramfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) and mtd might all permit this.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) - If the backing device can't or won't permit direct sharing,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) but does have the NOMMU_MAP_COPY capability, then a copy of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) appropriate bit of the file will be read into a contiguous bit of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) memory and any extraneous space beyond the EOF will be cleared
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) - Writes to the file do not affect the mapping; writes to the mapping
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) are visible in other processes (no MMU protection), but should not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) happen.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) (#) File, MAP_PRIVATE, PROT_READ / PROT_EXEC, PROT_WRITE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) In the MMU case: like the non-PROT_WRITE case, except that the pages in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) question get copied before the write actually happens. From that point
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) on writes to the file underneath that page no longer get reflected into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) the mapping's backing pages. The page is then backed by swap instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) In the no-MMU case: works much like the non-PROT_WRITE case, except
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) that a copy is always taken and never shared.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) (#) Regular file / blockdev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) In the MMU case: VM regions backed by pages read from file; changes to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) pages written back to file; writes to file reflected into pages backing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) mapping; shared across fork.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) In the no-MMU case: not supported.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) (#) Memory backed regular file, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) In the MMU case: As for ordinary regular files.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) In the no-MMU case: The filesystem providing the memory-backed file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) (such as ramfs or tmpfs) may choose to honour an open, truncate, mmap
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) sequence by providing a contiguous sequence of pages to map. In that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) case, a shared-writable memory mapping will be possible. It will work
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) as for the MMU case. If the filesystem does not provide any such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) support, then the mapping request will be denied.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) (#) Memory backed blockdev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) In the MMU case: As for ordinary regular files.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) In the no-MMU case: As for memory backed regular files, but the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) blockdev must be able to provide a contiguous run of pages without
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) truncate being called. The ramdisk driver could do this if it allocated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) all its memory as a contiguous array upfront.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) (#) Memory backed chardev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) In the MMU case: As for ordinary regular files.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) In the no-MMU case: The character device driver may choose to honour
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) the mmap() by providing direct access to the underlying device if it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) provides memory or quasi-memory that can be accessed directly. Examples
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) of such are frame buffers and flash devices. If the driver does not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) provide any such support, then the mapping request will be denied.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) Further notes on no-MMU MMAP
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) (#) A request for a private mapping of a file may return a buffer that is not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) page-aligned. This is because XIP may take place, and the data may not be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) paged aligned in the backing store.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) (#) A request for an anonymous mapping will always be page aligned. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) possible the size of the request should be a power of two otherwise some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) of the space may be wasted as the kernel must allocate a power-of-2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) granule but will only discard the excess if appropriately configured as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) this has an effect on fragmentation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) (#) The memory allocated by a request for an anonymous mapping will normally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) be cleared by the kernel before being returned in accordance with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) Linux man pages (ver 2.22 or later).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) In the MMU case this can be achieved with reasonable performance as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) regions are backed by virtual pages, with the contents only being mapped
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) to cleared physical pages when a write happens on that specific page
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) (prior to which, the pages are effectively mapped to the global zero page
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) from which reads can take place). This spreads out the time it takes to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) initialize the contents of a page - depending on the write-usage of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) mapping.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) In the no-MMU case, however, anonymous mappings are backed by physical
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) pages, and the entire map is cleared at allocation time. This can cause
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) significant delays during a userspace malloc() as the C library does an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) anonymous mapping and the kernel then does a memset for the entire map.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) However, for memory that isn't required to be precleared - such as that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) indicate to the kernel that it shouldn't bother clearing the memory before
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) returning it. Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) to permit this, otherwise the flag will be ignored.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) to allocate the brk and stack region.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) (#) A list of all the private copy and anonymous mappings on the system is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) visible through /proc/maps in no-MMU mode.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) (#) A list of all the mappings in use by a process is visible through
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) /proc/<pid>/maps in no-MMU mode.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) (#) Supplying MAP_FIXED or a requesting a particular mapping address will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) result in an error.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) (#) Files mapped privately usually have to have a read method provided by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) driver or filesystem so that the contents can be read into the memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) allocated if mmap() chooses not to map the backing device directly. An
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) error will result if they don't. This is most likely to be encountered
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) with character device files, pipes, fifos and sockets.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) Interprocess shared memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) ==========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) Both SYSV IPC SHM shared memory and POSIX shared memory is supported in NOMMU
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) mode. The former through the usual mechanism, the latter through files created
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) on ramfs or tmpfs mounts.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) Futexes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) =======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) Futexes are supported in NOMMU mode if the arch supports them. An error will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) be given if an address passed to the futex system call lies outside the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) mappings made by a process or if the mapping in which the address lies does not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) support futexes (such as an I/O chardev mapping).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) No-MMU mremap
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) The mremap() function is partially supported. It may change the size of a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) mapping, and may move it [#]_ if MREMAP_MAYMOVE is specified and if the new size
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) of the mapping exceeds the size of the slab object currently occupied by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) memory to which the mapping refers, or if a smaller slab object could be used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) MREMAP_FIXED is not supported, though it is ignored if there's no change of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) address and the object does not need to be moved.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) Shared mappings may not be moved. Shareable mappings may not be moved either,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) even if they are not currently shared.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) The mremap() function must be given an exact match for base address and size of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) a previously mapped object. It may not be used to create holes in existing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) mappings, move parts of existing mappings or resize parts of mappings. It must
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) act on a complete mapping.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) .. [#] Not currently supported.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) Providing shareable character device support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) ============================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) To provide shareable character device support, a driver must provide a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) file->f_op->get_unmapped_area() operation. The mmap() routines will call this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) to get a proposed address for the mapping. This may return an error if it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) doesn't wish to honour the mapping because it's too long, at a weird offset,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) under some unsupported combination of flags or whatever.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) The driver should also provide backing device information with capabilities set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) to indicate the permitted types of mapping on such devices. The default is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) assumed to be readable and writable, not executable, and only shareable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) directly (can't be copied).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) The file->f_op->mmap() operation will be called to actually inaugurate the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) mapping. It can be rejected at that point. Returning the ENOSYS error will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) cause the mapping to be copied instead if NOMMU_MAP_COPY is specified.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) The vm_ops->close() routine will be invoked when the last mapping on a chardev
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) is removed. An existing mapping will be shared, partially or not, if possible
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) without notifying the driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) It is permitted also for the file->f_op->get_unmapped_area() operation to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) return -ENOSYS. This will be taken to mean that this operation just doesn't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) want to handle it, despite the fact it's got an operation. For instance, it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) might try directing the call to a secondary driver which turns out not to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) implement it. Such is the case for the framebuffer driver which attempts to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) direct the call to the device-specific driver. Under such circumstances, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) mapping request will be rejected if NOMMU_MAP_COPY is not specified, and a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) copy mapped otherwise.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) .. important::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) Some types of device may present a different appearance to anyone
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) looking at them in certain modes. Flash chips can be like this; for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) instance if they're in programming or erase mode, you might see the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) status reflected in the mapping, instead of the data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) In such a case, care must be taken lest userspace see a shared or a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) private mapping showing such information when the driver is busy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) controlling the device. Remember especially: private executable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) mappings may still be mapped directly off the device under some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) circumstances!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) Providing shareable memory-backed file support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) ==============================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) Provision of shared mappings on memory backed files is similar to the provision
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) of support for shared mapped character devices. The main difference is that the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) filesystem providing the service will probably allocate a contiguous collection
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) of pages and permit mappings to be made on that.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) It is recommended that a truncate operation applied to such a file that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) increases the file size, if that file is empty, be taken as a request to gather
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) enough pages to honour a mapping. This is required to support POSIX shared
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) Memory backed devices are indicated by the mapping's backing device info having
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) the memory_backed flag set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) Providing shareable block device support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) ========================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) Provision of shared mappings on block device files is exactly the same as for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) character devices. If there isn't a real device underneath, then the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) should allocate sufficient contiguous memory to honour any supported mapping.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) Adjusting page trimming behaviour
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) =================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) NOMMU mmap automatically rounds up to the nearest power-of-2 number of pages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) when performing an allocation. This can have adverse effects on memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) fragmentation, and as such, is left configurable. The default behaviour is to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) aggressively trim allocations and discard any excess pages back in to the page
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) allocator. In order to retain finer-grained control over fragmentation, this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) behaviour can either be disabled completely, or bumped up to a higher page
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) watermark where trimming begins.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) Page trimming behaviour is configurable via the sysctl ``vm.nr_trim_pages``.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags