From e996919b7292d8aa1ff16d90b1e0684e7627fc53 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 14 Jun 2020 21:11:00 -0700 Subject: Documentation: fix sysctl/kernel.rst heading format warnings Fix heading format warnings in admin-guide/sysctl/kernel.rst: Documentation/admin-guide/sysctl/kernel.rst:339: WARNING: Title underline too short. hung_task_all_cpu_backtrace: ================ Documentation/admin-guide/sysctl/kernel.rst:650: WARNING: Title underline too short. oops_all_cpu_backtrace: ================ Fixes: 0ec9dc9bcba0 ("kernel/hung_task.c: introduce sysctl to print all traces when a hung task is detected") Fixes: 60c958d8df9c ("panic: add sysctl to dump all CPUs backtraces on oops event") Signed-off-by: Randy Dunlap Reviewed-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/8af1cb77-4b5a-64b9-da5d-f6a95e537f99@infradead.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/sysctl/kernel.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation/admin-guide/sysctl') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 83acf5025488..6d96f17b74a4 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -335,8 +335,8 @@ Path for the hotplug policy agent. Default value is "``/sbin/hotplug``". -hung_task_all_cpu_backtrace: -================ +hung_task_all_cpu_backtrace +=========================== If this option is set, the kernel will send an NMI to all CPUs to dump their backtraces when a hung task is detected. This file shows up if @@ -646,8 +646,8 @@ rate for each task. scanned for a given scan. -oops_all_cpu_backtrace: -================ +oops_all_cpu_backtrace +====================== If this option is set, the kernel will send an NMI to all CPUs to dump their backtraces when an oops event occurs. It should be used as a last -- cgit v1.2.3 From 0b227076d509c2facf177d7cdb67cbbb885cb661 Mon Sep 17 00:00:00 2001 From: Stephen Kitt Date: Tue, 23 Jun 2020 13:25:14 +0200 Subject: docs: sysctl/kernel: document random This documents the random directory, based on the behaviour seen in drivers/char/random.c. Signed-off-by: Stephen Kitt Link: https://lore.kernel.org/r/20200623112514.10650-1-steve@sk2.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/sysctl/kernel.rst | 32 +++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'Documentation/admin-guide/sysctl') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 6d96f17b74a4..5f432f51f23e 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -996,6 +996,38 @@ pty See Documentation/filesystems/devpts.rst. +random +====== + +This is a directory, with the following entries: + +* ``boot_id``: a UUID generated the first time this is retrieved, and + unvarying after that; + +* ``entropy_avail``: the pool's entropy count, in bits; + +* ``poolsize``: the entropy pool size, in bits; + +* ``urandom_min_reseed_secs``: obsolete (used to determine the minimum + number of seconds between urandom pool reseeding). + +* ``uuid``: a UUID generated every time this is retrieved (this can + thus be used to generate UUIDs at will); + +* ``write_wakeup_threshold``: when the entropy count drops below this + (as a number of bits), processes waiting to write to ``/dev/random`` + are woken up. + +If ``drivers/char/random.c`` is built with ``ADD_INTERRUPT_BENCH`` +defined, these additional entries are present: + +* ``add_interrupt_avg_cycles``: the average number of cycles between + interrupts used to feed the pool; + +* ``add_interrupt_avg_deviation``: the standard deviation seen on the + number of cycles between interrupts used to feed the pool. + + randomize_va_space ================== -- cgit v1.2.3 From 800c02f5d03019716a5926b73144be3bf0276923 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 23 Jun 2020 15:31:36 +0200 Subject: docs: move nommu-mmap.txt to admin-guide and rename to ReST The nommu-mmap.txt file provides description of user visible behaviuour. So, move it to the admin-guide. As it is already at the ReST, also rename it. Suggested-by: Mike Rapoport Suggested-by: Jonathan Corbet Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/3a63d1833b513700755c85bf3bda0a6c4ab56986.1592918949.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/mm/index.rst | 1 + Documentation/admin-guide/mm/nommu-mmap.rst | 283 ++++++++++++++++++++++++++++ Documentation/admin-guide/sysctl/vm.rst | 2 +- Documentation/gpu/drm-mm.rst | 2 +- Documentation/nommu-mmap.txt | 283 ---------------------------- init/Kconfig | 2 +- mm/Kconfig | 2 +- mm/nommu.c | 2 +- 8 files changed, 289 insertions(+), 288 deletions(-) create mode 100644 Documentation/admin-guide/mm/nommu-mmap.rst delete mode 100644 Documentation/nommu-mmap.txt (limited to 'Documentation/admin-guide/sysctl') diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst index 11db46448354..774dad6d3d29 100644 --- a/Documentation/admin-guide/mm/index.rst +++ b/Documentation/admin-guide/mm/index.rst @@ -31,6 +31,7 @@ the Linux memory management. idle_page_tracking ksm memory-hotplug + nommu-map numa_memory_policy numaperf pagemap diff --git a/Documentation/admin-guide/mm/nommu-mmap.rst b/Documentation/admin-guide/mm/nommu-mmap.rst new file mode 100644 index 000000000000..530fed08de2c --- /dev/null +++ b/Documentation/admin-guide/mm/nommu-mmap.rst @@ -0,0 +1,283 @@ +============================= +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 re-use 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 + + In the MMU case: VM regions backed by pages read from file; changes to + pages written back to file; writes to file reflected into pages backing + mapping; shared across fork. + + In the no-MMU case: not supported. + + (#) Memory backed regular file, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE + + In the MMU case: As for ordinary regular files. + + In the no-MMU case: The filesystem providing the memory-backed file + (such as ramfs or tmpfs) may choose to honour an open, truncate, mmap + sequence by providing a contiguous sequence of pages to map. In that + case, a shared-writable memory mapping will be possible. It will work + as for the MMU case. If the filesystem does not provide any such + support, then the mapping request will be denied. + + (#) Memory backed blockdev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE + + In the MMU case: As for ordinary regular files. + + In the no-MMU case: As for memory backed regular files, but the + blockdev must be able to provide a contiguous run of pages without + truncate being called. The ramdisk driver could do this if it allocated + all its memory as a contiguous array upfront. + + (#) Memory backed chardev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE + + In the MMU case: As for ordinary regular files. + + In the no-MMU case: The character device driver may choose to honour + the mmap() by providing direct access to the underlying device if it + provides memory or quasi-memory that can be accessed directly. Examples + of such are frame buffers and flash devices. If the driver does not + provide any such support, then the mapping request will be denied. + + +Further notes on no-MMU MMAP +============================ + + (#) A request for a private mapping of a file may return a buffer that is not + page-aligned. This is because XIP may take place, and the data may not be + paged aligned in the backing store. + + (#) A request for an anonymous mapping will always be page aligned. If + possible the size of the request should be a power of two otherwise some + of the space may be wasted as the kernel must allocate a power-of-2 + granule but will only discard the excess if appropriately configured as + this has an effect on fragmentation. + + (#) The memory allocated by a request for an anonymous mapping will normally + be cleared by the kernel before being returned in accordance with the + Linux man pages (ver 2.22 or later). + + In the MMU case this can be achieved with reasonable performance as + regions are backed by virtual pages, with the contents only being mapped + to cleared physical pages when a write happens on that specific page + (prior to which, the pages are effectively mapped to the global zero page + from which reads can take place). This spreads out the time it takes to + initialize the contents of a page - depending on the write-usage of the + mapping. + + In the no-MMU case, however, anonymous mappings are backed by physical + pages, and the entire map is cleared at allocation time. This can cause + significant delays during a userspace malloc() as the C library does an + anonymous mapping and the kernel then does a memset for the entire map. + + However, for memory that isn't required to be precleared - such as that + returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to + indicate to the kernel that it shouldn't bother clearing the memory before + returning it. Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled + to permit this, otherwise the flag will be ignored. + + uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this + to allocate the brk and stack region. + + (#) A list of all the private copy and anonymous mappings on the system is + visible through /proc/maps in no-MMU mode. + + (#) A list of all the mappings in use by a process is visible through + /proc//maps in no-MMU mode. + + (#) Supplying MAP_FIXED or a requesting a particular mapping address will + result in an error. + + (#) Files mapped privately usually have to have a read method provided by the + driver or filesystem so that the contents can be read into the memory + allocated if mmap() chooses not to map the backing device directly. An + error will result if they don't. This is most likely to be encountered + with character device files, pipes, fifos and sockets. + + +Interprocess shared memory +========================== + +Both SYSV IPC SHM shared memory and POSIX shared memory is supported in NOMMU +mode. The former through the usual mechanism, the latter through files created +on ramfs or tmpfs mounts. + + +Futexes +======= + +Futexes are supported in NOMMU mode if the arch supports them. An error will +be given if an address passed to the futex system call lies outside the +mappings made by a process or if the mapping in which the address lies does not +support futexes (such as an I/O chardev mapping). + + +No-MMU mremap +============= + +The mremap() function is partially supported. It may change the size of a +mapping, and may move it [#]_ if MREMAP_MAYMOVE is specified and if the new size +of the mapping exceeds the size of the slab object currently occupied by the +memory to which the mapping refers, or if a smaller slab object could be used. + +MREMAP_FIXED is not supported, though it is ignored if there's no change of +address and the object does not need to be moved. + +Shared mappings may not be moved. Shareable mappings may not be moved either, +even if they are not currently shared. + +The mremap() function must be given an exact match for base address and size of +a previously mapped object. It may not be used to create holes in existing +mappings, move parts of existing mappings or resize parts of mappings. It must +act on a complete mapping. + +.. [#] Not currently supported. + + +Providing shareable character device support +============================================ + +To provide shareable character device support, a driver must provide a +file->f_op->get_unmapped_area() operation. The mmap() routines will call this +to get a proposed address for the mapping. This may return an error if it +doesn't wish to honour the mapping because it's too long, at a weird offset, +under some unsupported combination of flags or whatever. + +The driver should also provide backing device information with capabilities set +to indicate the permitted types of mapping on such devices. The default is +assumed to be readable and writable, not executable, and only shareable +directly (can't be copied). + +The file->f_op->mmap() operation will be called to actually inaugurate the +mapping. It can be rejected at that point. Returning the ENOSYS error will +cause the mapping to be copied instead if NOMMU_MAP_COPY is specified. + +The vm_ops->close() routine will be invoked when the last mapping on a chardev +is removed. An existing mapping will be shared, partially or not, if possible +without notifying the driver. + +It is permitted also for the file->f_op->get_unmapped_area() operation to +return -ENOSYS. This will be taken to mean that this operation just doesn't +want to handle it, despite the fact it's got an operation. For instance, it +might try directing the call to a secondary driver which turns out not to +implement it. Such is the case for the framebuffer driver which attempts to +direct the call to the device-specific driver. Under such circumstances, the +mapping request will be rejected if NOMMU_MAP_COPY is not specified, and a +copy mapped otherwise. + +.. important:: + + Some types of device may present a different appearance to anyone + looking at them in certain modes. Flash chips can be like this; for + instance if they're in programming or erase mode, you might see the + status reflected in the mapping, instead of the data. + + In such a case, care must be taken lest userspace see a shared or a + private mapping showing such information when the driver is busy + controlling the device. Remember especially: private executable + mappings may still be mapped directly off the device under some + circumstances! + + +Providing shareable memory-backed file support +============================================== + +Provision of shared mappings on memory backed files is similar to the provision +of support for shared mapped character devices. The main difference is that the +filesystem providing the service will probably allocate a contiguous collection +of pages and permit mappings to be made on that. + +It is recommended that a truncate operation applied to such a file that +increases the file size, if that file is empty, be taken as a request to gather +enough pages to honour a mapping. This is required to support POSIX shared +memory. + +Memory backed devices are indicated by the mapping's backing device info having +the memory_backed flag set. + + +Providing shareable block device support +======================================== + +Provision of shared mappings on block device files is exactly the same as for +character devices. If there isn't a real device underneath, then the driver +should allocate sufficient contiguous memory to honour any supported mapping. + + +Adjusting page trimming behaviour +================================= + +NOMMU mmap automatically rounds up to the nearest power-of-2 number of pages +when performing an allocation. This can have adverse effects on memory +fragmentation, and as such, is left configurable. The default behaviour is to +aggressively trim allocations and discard any excess pages back in to the page +allocator. In order to retain finer-grained control over fragmentation, this +behaviour can either be disabled completely, or bumped up to a higher page +watermark where trimming begins. + +Page trimming behaviour is configurable via the sysctl ``vm.nr_trim_pages``. diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index d46d5b7013c6..d997cc3c26d0 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -583,7 +583,7 @@ trimming of allocations is initiated. The default value is 1. -See Documentation/nommu-mmap.txt for more information. +See Documentation/admin-guide/mm/nommu-mmap.rst for more information. numa_zonelist_order diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 1839762044be..49d321eb7964 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -314,7 +314,7 @@ To use drm_gem_cma_get_unmapped_area(), drivers must fill the struct a pointer on drm_gem_cma_get_unmapped_area(). More detailed information about get_unmapped_area can be found in -Documentation/nommu-mmap.txt +Documentation/admin-guide/mm/nommu-mmap.rst Memory Coherency ---------------- diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt deleted file mode 100644 index 530fed08de2c..000000000000 --- a/Documentation/nommu-mmap.txt +++ /dev/null @@ -1,283 +0,0 @@ -============================= -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 re-use 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 - - In the MMU case: VM regions backed by pages read from file; changes to - pages written back to file; writes to file reflected into pages backing - mapping; shared across fork. - - In the no-MMU case: not supported. - - (#) Memory backed regular file, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE - - In the MMU case: As for ordinary regular files. - - In the no-MMU case: The filesystem providing the memory-backed file - (such as ramfs or tmpfs) may choose to honour an open, truncate, mmap - sequence by providing a contiguous sequence of pages to map. In that - case, a shared-writable memory mapping will be possible. It will work - as for the MMU case. If the filesystem does not provide any such - support, then the mapping request will be denied. - - (#) Memory backed blockdev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE - - In the MMU case: As for ordinary regular files. - - In the no-MMU case: As for memory backed regular files, but the - blockdev must be able to provide a contiguous run of pages without - truncate being called. The ramdisk driver could do this if it allocated - all its memory as a contiguous array upfront. - - (#) Memory backed chardev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE - - In the MMU case: As for ordinary regular files. - - In the no-MMU case: The character device driver may choose to honour - the mmap() by providing direct access to the underlying device if it - provides memory or quasi-memory that can be accessed directly. Examples - of such are frame buffers and flash devices. If the driver does not - provide any such support, then the mapping request will be denied. - - -Further notes on no-MMU MMAP -============================ - - (#) A request for a private mapping of a file may return a buffer that is not - page-aligned. This is because XIP may take place, and the data may not be - paged aligned in the backing store. - - (#) A request for an anonymous mapping will always be page aligned. If - possible the size of the request should be a power of two otherwise some - of the space may be wasted as the kernel must allocate a power-of-2 - granule but will only discard the excess if appropriately configured as - this has an effect on fragmentation. - - (#) The memory allocated by a request for an anonymous mapping will normally - be cleared by the kernel before being returned in accordance with the - Linux man pages (ver 2.22 or later). - - In the MMU case this can be achieved with reasonable performance as - regions are backed by virtual pages, with the contents only being mapped - to cleared physical pages when a write happens on that specific page - (prior to which, the pages are effectively mapped to the global zero page - from which reads can take place). This spreads out the time it takes to - initialize the contents of a page - depending on the write-usage of the - mapping. - - In the no-MMU case, however, anonymous mappings are backed by physical - pages, and the entire map is cleared at allocation time. This can cause - significant delays during a userspace malloc() as the C library does an - anonymous mapping and the kernel then does a memset for the entire map. - - However, for memory that isn't required to be precleared - such as that - returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to - indicate to the kernel that it shouldn't bother clearing the memory before - returning it. Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled - to permit this, otherwise the flag will be ignored. - - uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this - to allocate the brk and stack region. - - (#) A list of all the private copy and anonymous mappings on the system is - visible through /proc/maps in no-MMU mode. - - (#) A list of all the mappings in use by a process is visible through - /proc//maps in no-MMU mode. - - (#) Supplying MAP_FIXED or a requesting a particular mapping address will - result in an error. - - (#) Files mapped privately usually have to have a read method provided by the - driver or filesystem so that the contents can be read into the memory - allocated if mmap() chooses not to map the backing device directly. An - error will result if they don't. This is most likely to be encountered - with character device files, pipes, fifos and sockets. - - -Interprocess shared memory -========================== - -Both SYSV IPC SHM shared memory and POSIX shared memory is supported in NOMMU -mode. The former through the usual mechanism, the latter through files created -on ramfs or tmpfs mounts. - - -Futexes -======= - -Futexes are supported in NOMMU mode if the arch supports them. An error will -be given if an address passed to the futex system call lies outside the -mappings made by a process or if the mapping in which the address lies does not -support futexes (such as an I/O chardev mapping). - - -No-MMU mremap -============= - -The mremap() function is partially supported. It may change the size of a -mapping, and may move it [#]_ if MREMAP_MAYMOVE is specified and if the new size -of the mapping exceeds the size of the slab object currently occupied by the -memory to which the mapping refers, or if a smaller slab object could be used. - -MREMAP_FIXED is not supported, though it is ignored if there's no change of -address and the object does not need to be moved. - -Shared mappings may not be moved. Shareable mappings may not be moved either, -even if they are not currently shared. - -The mremap() function must be given an exact match for base address and size of -a previously mapped object. It may not be used to create holes in existing -mappings, move parts of existing mappings or resize parts of mappings. It must -act on a complete mapping. - -.. [#] Not currently supported. - - -Providing shareable character device support -============================================ - -To provide shareable character device support, a driver must provide a -file->f_op->get_unmapped_area() operation. The mmap() routines will call this -to get a proposed address for the mapping. This may return an error if it -doesn't wish to honour the mapping because it's too long, at a weird offset, -under some unsupported combination of flags or whatever. - -The driver should also provide backing device information with capabilities set -to indicate the permitted types of mapping on such devices. The default is -assumed to be readable and writable, not executable, and only shareable -directly (can't be copied). - -The file->f_op->mmap() operation will be called to actually inaugurate the -mapping. It can be rejected at that point. Returning the ENOSYS error will -cause the mapping to be copied instead if NOMMU_MAP_COPY is specified. - -The vm_ops->close() routine will be invoked when the last mapping on a chardev -is removed. An existing mapping will be shared, partially or not, if possible -without notifying the driver. - -It is permitted also for the file->f_op->get_unmapped_area() operation to -return -ENOSYS. This will be taken to mean that this operation just doesn't -want to handle it, despite the fact it's got an operation. For instance, it -might try directing the call to a secondary driver which turns out not to -implement it. Such is the case for the framebuffer driver which attempts to -direct the call to the device-specific driver. Under such circumstances, the -mapping request will be rejected if NOMMU_MAP_COPY is not specified, and a -copy mapped otherwise. - -.. important:: - - Some types of device may present a different appearance to anyone - looking at them in certain modes. Flash chips can be like this; for - instance if they're in programming or erase mode, you might see the - status reflected in the mapping, instead of the data. - - In such a case, care must be taken lest userspace see a shared or a - private mapping showing such information when the driver is busy - controlling the device. Remember especially: private executable - mappings may still be mapped directly off the device under some - circumstances! - - -Providing shareable memory-backed file support -============================================== - -Provision of shared mappings on memory backed files is similar to the provision -of support for shared mapped character devices. The main difference is that the -filesystem providing the service will probably allocate a contiguous collection -of pages and permit mappings to be made on that. - -It is recommended that a truncate operation applied to such a file that -increases the file size, if that file is empty, be taken as a request to gather -enough pages to honour a mapping. This is required to support POSIX shared -memory. - -Memory backed devices are indicated by the mapping's backing device info having -the memory_backed flag set. - - -Providing shareable block device support -======================================== - -Provision of shared mappings on block device files is exactly the same as for -character devices. If there isn't a real device underneath, then the driver -should allocate sufficient contiguous memory to honour any supported mapping. - - -Adjusting page trimming behaviour -================================= - -NOMMU mmap automatically rounds up to the nearest power-of-2 number of pages -when performing an allocation. This can have adverse effects on memory -fragmentation, and as such, is left configurable. The default behaviour is to -aggressively trim allocations and discard any excess pages back in to the page -allocator. In order to retain finer-grained control over fragmentation, this -behaviour can either be disabled completely, or bumped up to a higher page -watermark where trimming begins. - -Page trimming behaviour is configurable via the sysctl ``vm.nr_trim_pages``. diff --git a/init/Kconfig b/init/Kconfig index a46aa8f3174d..2dd5531dae98 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1957,7 +1957,7 @@ config MMAP_ALLOW_UNINITIALIZED userspace. Since that isn't generally a problem on no-MMU systems, it is normally safe to say Y here. - See Documentation/nommu-mmap.txt for more information. + See Documentation/mm/nommu-mmap.rst for more information. config SYSTEM_DATA_VERIFICATION def_bool n diff --git a/mm/Kconfig b/mm/Kconfig index f2104cc0d35c..d41f3fa7e923 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -387,7 +387,7 @@ config NOMMU_INITIAL_TRIM_EXCESS This option specifies the initial value of this option. The default of 1 says that all excess pages should be trimmed. - See Documentation/nommu-mmap.txt for more information. + See Documentation/mm/nommu-mmap.rst for more information. config TRANSPARENT_HUGEPAGE bool "Transparent Hugepage Support" diff --git a/mm/nommu.c b/mm/nommu.c index cdcad5d61dd1..64539971188b 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -5,7 +5,7 @@ * Replacement code for mm functions to support CPU's that don't * have any form of memory management unit (thus no virtual memory). * - * See Documentation/nommu-mmap.txt + * See Documentation/mm/nommu-mmap.rst * * Copyright (c) 2004-2008 David Howells * Copyright (c) 2000-2003 David McCullough -- cgit v1.2.3 From ee74db082abf8f4ce2ef534da4ed8950de21ae29 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Fri, 3 Jul 2020 20:20:18 -0700 Subject: Documentation/admin-guide: sysctl/kernel: drop doubled word Drop the doubled word "set". Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/20200704032020.21923-12-rdunlap@infradead.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/sysctl/kernel.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/admin-guide/sysctl') diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 5f432f51f23e..292e3d0188f6 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -235,7 +235,7 @@ This toggle indicates whether unprivileged users are prevented from using ``dmesg(8)`` to view messages from the kernel's log buffer. When ``dmesg_restrict`` is set to 0 there are no restrictions. -When ``dmesg_restrict`` is set set to 1, users must have +When ``dmesg_restrict`` is set to 1, users must have ``CAP_SYSLOG`` to use ``dmesg(8)``. The kernel config option ``CONFIG_SECURITY_DMESG_RESTRICT`` sets the -- cgit v1.2.3 From 6b2484e13a52e9836e67e89cadc6189c40c8ae8c Mon Sep 17 00:00:00 2001 From: "Alexander A. Klimov" Date: Sat, 27 Jun 2020 09:29:35 +0200 Subject: Replace HTTP links with HTTPS ones: Documentation/admin-guide Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov Link: https://lore.kernel.org/r/20200627072935.62652-1-grandmaster@al2klimov.de Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/dell_rbu.rst | 2 +- Documentation/admin-guide/devices.txt | 6 +++--- Documentation/admin-guide/ext4.rst | 4 ++-- Documentation/admin-guide/kernel-parameters.txt | 2 +- Documentation/admin-guide/laptops/disk-shock-protection.rst | 2 +- Documentation/admin-guide/laptops/sonypi.rst | 2 +- Documentation/admin-guide/laptops/thinkpad-acpi.rst | 6 +++--- Documentation/admin-guide/mm/ksm.rst | 2 +- Documentation/admin-guide/nfs/nfs-client.rst | 4 ++-- Documentation/admin-guide/nfs/nfs-rdma.rst | 2 +- Documentation/admin-guide/nfs/nfsroot.rst | 6 +++--- Documentation/admin-guide/sysctl/fs.rst | 2 +- 12 files changed, 20 insertions(+), 20 deletions(-) (limited to 'Documentation/admin-guide/sysctl') diff --git a/Documentation/admin-guide/dell_rbu.rst b/Documentation/admin-guide/dell_rbu.rst index 8d70e1fc9f9d..2196caf1b939 100644 --- a/Documentation/admin-guide/dell_rbu.rst +++ b/Documentation/admin-guide/dell_rbu.rst @@ -26,7 +26,7 @@ Please go to http://support.dell.com register and you can find info on OpenManage and Dell Update packages (DUP). Libsmbios can also be used to update BIOS on Dell systems go to -http://linux.dell.com/libsmbios/ for details. +https://linux.dell.com/libsmbios/ for details. Dell_RBU driver supports BIOS update using the monolithic image and packetized image methods. In case of monolithic the driver allocates a contiguous chunk diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt index 2a97aaec8b12..a622dfec92a4 100644 --- a/Documentation/admin-guide/devices.txt +++ b/Documentation/admin-guide/devices.txt @@ -1442,7 +1442,7 @@ ... The driver and documentation may be obtained from - http://www.winradio.com/ + https://www.winradio.com/ 82 block I2O hard disk 0 = /dev/i2o/hdag 33rd I2O hard disk, whole disk @@ -1656,7 +1656,7 @@ dynamically, so there is no fixed mapping from subdevice pathnames to minor numbers. - See http://www.comedi.org/ for information about the Comedi + See https://www.comedi.org/ for information about the Comedi project. 98 block User-mode virtual block device @@ -1723,7 +1723,7 @@ implementations a kernel presence for caching and easy mounting. For more information about the project, write to or see - http://www.stacken.kth.se/project/arla/ + https://www.stacken.kth.se/project/arla/ 103 block Audit device 0 = /dev/audit Audit device diff --git a/Documentation/admin-guide/ext4.rst b/Documentation/admin-guide/ext4.rst index 9443fcef1876..bc3abfb33476 100644 --- a/Documentation/admin-guide/ext4.rst +++ b/Documentation/admin-guide/ext4.rst @@ -611,7 +611,7 @@ kernel source: programs: http://e2fsprogs.sourceforge.net/ -useful links: http://fedoraproject.org/wiki/ext3-devel +useful links: https://fedoraproject.org/wiki/ext3-devel http://www.bullopensource.org/ext4/ http://ext4.wiki.kernel.org/index.php/Main_Page - http://fedoraproject.org/wiki/Features/Ext4 + https://fedoraproject.org/wiki/Features/Ext4 diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index b5beb1fe78cf..d325726ff425 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2788,7 +2788,7 @@ touchscreen support is not enabled in the mainstream kernel as of 2.6.30, a preliminary port can be found in the "bleeding edge" mini2440 support kernel at - http://repo.or.cz/w/linux-2.6/mini2440.git + https://repo.or.cz/w/linux-2.6/mini2440.git mitigations= [X86,PPC,S390,ARM64] Control optional mitigations for diff --git a/Documentation/admin-guide/laptops/disk-shock-protection.rst b/Documentation/admin-guide/laptops/disk-shock-protection.rst index e97c5f78d8c3..22c7ec3e84cf 100644 --- a/Documentation/admin-guide/laptops/disk-shock-protection.rst +++ b/Documentation/admin-guide/laptops/disk-shock-protection.rst @@ -135,7 +135,7 @@ single project which, although still considered experimental, is fit for use. Please feel free to add projects that have been the victims of my ignorance. -- http://www.thinkwiki.org/wiki/HDAPS +- https://www.thinkwiki.org/wiki/HDAPS See this page for information about Linux support of the hard disk active protection system as implemented in IBM/Lenovo Thinkpads. diff --git a/Documentation/admin-guide/laptops/sonypi.rst b/Documentation/admin-guide/laptops/sonypi.rst index c6eaaf48f7c1..190da1234314 100644 --- a/Documentation/admin-guide/laptops/sonypi.rst +++ b/Documentation/admin-guide/laptops/sonypi.rst @@ -151,7 +151,7 @@ Bugs: different way to adjust the backlighting of the screen. There is a userspace utility to adjust the brightness on those models, which can be downloaded from - http://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2 + https://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2 - since all development was done by reverse engineering, there is *absolutely no guarantee* that this driver will not crash your diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst index 822907dcc845..69b7ce905cba 100644 --- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst +++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst @@ -904,7 +904,7 @@ temperatures: The mapping of thermal sensors to physical locations varies depending on system-board model (and thus, on ThinkPad model). -http://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that +https://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that tries to track down these locations for various models. Most (newer?) models seem to follow this pattern: @@ -925,7 +925,7 @@ For the R51 (source: Thomas Gruber): - 3: Internal HDD For the T43, T43/p (source: Shmidoax/Thinkwiki.org) -http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p +https://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p - 2: System board, left side (near PCMCIA slot), reported as HDAPS temp - 3: PCMCIA slot @@ -935,7 +935,7 @@ http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p - 11: Power regulator, underside of system board, below F2 key The A31 has a very atypical layout for the thermal sensors -(source: Milos Popovic, http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31) +(source: Milos Popovic, https://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31) - 1: CPU - 2: Main Battery: main sensor diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst index 3deeb2a2c4f9..97d816791aca 100644 --- a/Documentation/admin-guide/mm/ksm.rst +++ b/Documentation/admin-guide/mm/ksm.rst @@ -9,7 +9,7 @@ Overview KSM is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y, added to the Linux kernel in 2.6.32. See ``mm/ksm.c`` for its implementation, -and http://lwn.net/Articles/306704/ and http://lwn.net/Articles/330589/ +and http://lwn.net/Articles/306704/ and https://lwn.net/Articles/330589/ KSM was originally developed for use with KVM (where it was known as Kernel Shared Memory), to fit more virtual machines into physical memory, diff --git a/Documentation/admin-guide/nfs/nfs-client.rst b/Documentation/admin-guide/nfs/nfs-client.rst index c4b777c7584b..6adb6457bc69 100644 --- a/Documentation/admin-guide/nfs/nfs-client.rst +++ b/Documentation/admin-guide/nfs/nfs-client.rst @@ -65,8 +65,8 @@ migrated onto another server by means of the special "fs_locations" attribute. See `RFC3530 Section 6: Filesystem Migration and Replication`_ and `Implementation Guide for Referrals in NFSv4`_. -.. _RFC3530 Section 6\: Filesystem Migration and Replication: http://tools.ietf.org/html/rfc3530#section-6 -.. _Implementation Guide for Referrals in NFSv4: http://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00 +.. _RFC3530 Section 6\: Filesystem Migration and Replication: https://tools.ietf.org/html/rfc3530#section-6 +.. _Implementation Guide for Referrals in NFSv4: https://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00 The fs_locations information can take the form of either an ip address and a path, or a DNS hostname and a path. The latter requires the NFS client to diff --git a/Documentation/admin-guide/nfs/nfs-rdma.rst b/Documentation/admin-guide/nfs/nfs-rdma.rst index ef0f3678b1fb..f137485f8bde 100644 --- a/Documentation/admin-guide/nfs/nfs-rdma.rst +++ b/Documentation/admin-guide/nfs/nfs-rdma.rst @@ -65,7 +65,7 @@ use with NFS/RDMA. If the version is less than 1.1.2 or the command does not exist, you should install the latest version of nfs-utils. - Download the latest package from: http://www.kernel.org/pub/linux/utils/nfs + Download the latest package from: https://www.kernel.org/pub/linux/utils/nfs Uncompress the package and follow the installation instructions. diff --git a/Documentation/admin-guide/nfs/nfsroot.rst b/Documentation/admin-guide/nfs/nfsroot.rst index c6772075c80c..135218f33394 100644 --- a/Documentation/admin-guide/nfs/nfsroot.rst +++ b/Documentation/admin-guide/nfs/nfsroot.rst @@ -264,7 +264,7 @@ They depend on various facilities being available: access to the floppy drive device, /dev/fd0 For more information on syslinux, including how to create bootdisks - for prebuilt kernels, see http://syslinux.zytor.com/ + for prebuilt kernels, see https://syslinux.zytor.com/ .. note:: Previously it was possible to write a kernel directly to @@ -292,7 +292,7 @@ They depend on various facilities being available: cdrecord dev=ATAPI:1,0,0 arch/x86/boot/image.iso For more information on isolinux, including how to create bootdisks - for prebuilt kernels, see http://syslinux.zytor.com/ + for prebuilt kernels, see https://syslinux.zytor.com/ - Using LILO @@ -346,7 +346,7 @@ They depend on various facilities being available: see Documentation/admin-guide/serial-console.rst for more information. For more information on isolinux, including how to create bootdisks - for prebuilt kernels, see http://syslinux.zytor.com/ + for prebuilt kernels, see https://syslinux.zytor.com/ diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst index 2a45119e3331..f48277a0a850 100644 --- a/Documentation/admin-guide/sysctl/fs.rst +++ b/Documentation/admin-guide/sysctl/fs.rst @@ -261,7 +261,7 @@ directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given symlink (i.e. a root process follows a symlink belonging to another user). For a likely incomplete list of hundreds of examples across the years, please see: -http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp +https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp When set to "0", symlink following behavior is unrestricted. -- cgit v1.2.3