From d25e92d2aed9cdff2a2222e82412a53f70e17c1a Mon Sep 17 00:00:00 2001 From: Wang Jinchao Date: Fri, 22 Sep 2023 10:00:21 +0800 Subject: memory-hotplug.rst: fix wrong /sys/device/ path Actually, it should be /sys/devices/ Signed-off-by: Wang Jinchao Reviewed-by: David Hildenbrand Signed-off-by: Jonathan Corbet Message-ID: --- Documentation/admin-guide/mm/memory-hotplug.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation/admin-guide') diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index cfe034cf1e87..01595965734a 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -250,15 +250,15 @@ Observing the State of Memory Blocks The state (online/offline/going-offline) of a memory block can be observed either via:: - % cat /sys/device/system/memory/memoryXXX/state + % cat /sys/devices/system/memory/memoryXXX/state Or alternatively (1/0) via:: - % cat /sys/device/system/memory/memoryXXX/online + % cat /sys/devices/system/memory/memoryXXX/online For an online memory block, the managing zone can be observed via:: - % cat /sys/device/system/memory/memoryXXX/valid_zones + % cat /sys/devices/system/memory/memoryXXX/valid_zones Configuring Memory Hot(Un)Plug ============================== @@ -326,7 +326,7 @@ however, a memory block might span memory holes. A memory block spanning memory holes cannot be offlined. For example, assume 1 GiB memory block size. A device for a memory starting at -0x100000000 is ``/sys/device/system/memory/memory4``:: +0x100000000 is ``/sys/devices/system/memory/memory4``:: (0x100000000 / 1Gib = 4) -- cgit From e4c0138ab396c727e6d5ca83cfe2e3d5b00be97c Mon Sep 17 00:00:00 2001 From: Mikko Rapeli Date: Mon, 4 Sep 2023 14:32:14 +0300 Subject: Documentation efi-stub.rst: fix arm64 EFI source location arch/arm64/kernel/efi-entry.S has been moved to drivers/firmware/efi/libstub/arm64-entry.S by commit v6.1-rc4-6-g4ef806096bdb and to drivers/firmware/efi/libstub/arm64.c by commit v6.2-rc3-6-g617861703830 Signed-off-by: Mikko Rapeli Acked-by: Ard Biesheuvel Signed-off-by: Jonathan Corbet Message-ID: <20230904113214.4147021-1-mikko.rapeli@linaro.org> --- Documentation/admin-guide/efi-stub.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/admin-guide') diff --git a/Documentation/admin-guide/efi-stub.rst b/Documentation/admin-guide/efi-stub.rst index b24e7c40d832..090f3a185e18 100644 --- a/Documentation/admin-guide/efi-stub.rst +++ b/Documentation/admin-guide/efi-stub.rst @@ -15,7 +15,7 @@ between architectures is in drivers/firmware/efi/libstub. For arm64, there is no compressed kernel support, so the Image itself masquerades as a PE/COFF image and the EFI stub is linked into the -kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S +kernel. The arm64 EFI stub lives in drivers/firmware/efi/libstub/arm64.c and drivers/firmware/efi/libstub/arm64-stub.c. By using the EFI boot stub it's possible to boot a Linux kernel -- cgit From 92224e806f7c8e133b2249408958ca988cf7413f Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 23 Sep 2023 12:51:44 -0700 Subject: docs: admin-guide: sysctl: fix details of struct dentry_stat_t Commit c8c0c239d5ab moved struct dentry_stat_t to fs/dcache.c but did not update its location in Documentation, so update that now. Also change each struct member from int to long as done in commit 3942c07ccf98. Fixes: c8c0c239d5ab ("fs: move dcache sysctls to its own file") Fixes: 3942c07ccf98 ("fs: bump inode and dentry counters to long") Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Cc: Alexander Viro Cc: Christian Brauner Cc: linux-fsdevel@vger.kernel.org Cc: Luis Chamberlain Cc: Arnd Bergmann Cc: Glauber Costa Acked-by: Christian Brauner Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20230923195144.26043-1-rdunlap@infradead.org --- Documentation/admin-guide/sysctl/fs.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) (limited to 'Documentation/admin-guide') diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst index a321b84eccaa..47499a1742bd 100644 --- a/Documentation/admin-guide/sysctl/fs.rst +++ b/Documentation/admin-guide/sysctl/fs.rst @@ -42,16 +42,16 @@ pre-allocation or re-sizing of any kernel data structures. dentry-state ------------ -This file shows the values in ``struct dentry_stat``, as defined in -``linux/include/linux/dcache.h``:: +This file shows the values in ``struct dentry_stat_t``, as defined in +``fs/dcache.c``:: struct dentry_stat_t dentry_stat { - int nr_dentry; - int nr_unused; - int age_limit; /* age in seconds */ - int want_pages; /* pages requested by system */ - int nr_negative; /* # of unused negative dentries */ - int dummy; /* Reserved for future use */ + long nr_dentry; + long nr_unused; + long age_limit; /* age in seconds */ + long want_pages; /* pages requested by system */ + long nr_negative; /* # of unused negative dentries */ + long dummy; /* Reserved for future use */ }; Dentries are dynamically allocated and deallocated. -- cgit From a3c12cf3a69150adb4a8fd199e4c78d4a9e65509 Mon Sep 17 00:00:00 2001 From: Takahiro Itazuri Date: Fri, 1 Sep 2023 09:29:59 +0100 Subject: docs/hw-vuln: Update desc of best effort mode Moves the description of the best effort mitigation mode to the table of the possible values in the mds and tsx_async_abort docs, and adds the same one to the mmio_stale_data doc. Signed-off-by: Takahiro Itazuri Reviewed-by: Pawan Gupta Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20230901082959.28310-1-itazur@amazon.com --- Documentation/admin-guide/hw-vuln/mds.rst | 34 +++++++++------------- .../hw-vuln/processor_mmio_stale_data.rst | 13 ++++++++- .../admin-guide/hw-vuln/tsx_async_abort.rst | 33 +++++++++------------ 3 files changed, 38 insertions(+), 42 deletions(-) (limited to 'Documentation/admin-guide') diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst index 48ca0bd85604..48c7b0b72aed 100644 --- a/Documentation/admin-guide/hw-vuln/mds.rst +++ b/Documentation/admin-guide/hw-vuln/mds.rst @@ -102,9 +102,19 @@ The possible values in this file are: * - 'Vulnerable' - The processor is vulnerable, but no mitigation enabled * - 'Vulnerable: Clear CPU buffers attempted, no microcode' - - The processor is vulnerable but microcode is not updated. - - The mitigation is enabled on a best effort basis. See :ref:`vmwerv` + - The processor is vulnerable but microcode is not updated. The + mitigation is enabled on a best effort basis. + + If the processor is vulnerable but the availability of the microcode + based mitigation mechanism is not advertised via CPUID, the kernel + selects a best effort mitigation mode. This mode invokes the mitigation + instructions without a guarantee that they clear the CPU buffers. + + This is done to address virtualization scenarios where the host has the + microcode update applied, but the hypervisor is not yet updated to + expose the CPUID to the guest. If the host has updated microcode the + protection takes effect; otherwise a few CPU cycles are wasted + pointlessly. * - 'Mitigation: Clear CPU buffers' - The processor is vulnerable and the CPU buffer clearing mitigation is enabled. @@ -119,24 +129,6 @@ to the above information: 'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown ======================== ============================================ -.. _vmwerv: - -Best effort mitigation mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - If the processor is vulnerable, but the availability of the microcode based - mitigation mechanism is not advertised via CPUID the kernel selects a best - effort mitigation mode. This mode invokes the mitigation instructions - without a guarantee that they clear the CPU buffers. - - This is done to address virtualization scenarios where the host has the - microcode update applied, but the hypervisor is not yet updated to expose - the CPUID to the guest. If the host has updated microcode the protection - takes effect otherwise a few cpu cycles are wasted pointlessly. - - The state in the mds sysfs file reflects this situation accordingly. - - Mitigation mechanism ------------------------- diff --git a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst index c98fd11907cc..1302fd1b55e8 100644 --- a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst +++ b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst @@ -225,8 +225,19 @@ The possible values in this file are: * - 'Vulnerable' - The processor is vulnerable, but no mitigation enabled * - 'Vulnerable: Clear CPU buffers attempted, no microcode' - - The processor is vulnerable, but microcode is not updated. The + - The processor is vulnerable but microcode is not updated. The mitigation is enabled on a best effort basis. + + If the processor is vulnerable but the availability of the microcode + based mitigation mechanism is not advertised via CPUID, the kernel + selects a best effort mitigation mode. This mode invokes the mitigation + instructions without a guarantee that they clear the CPU buffers. + + This is done to address virtualization scenarios where the host has the + microcode update applied, but the hypervisor is not yet updated to + expose the CPUID to the guest. If the host has updated microcode the + protection takes effect; otherwise a few CPU cycles are wasted + pointlessly. * - 'Mitigation: Clear CPU buffers' - The processor is vulnerable and the CPU buffer clearing mitigation is enabled. diff --git a/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst b/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst index 014167ef8dd1..444f84e22a91 100644 --- a/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst +++ b/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst @@ -98,7 +98,19 @@ The possible values in this file are: * - 'Vulnerable' - The CPU is affected by this vulnerability and the microcode and kernel mitigation are not applied. * - 'Vulnerable: Clear CPU buffers attempted, no microcode' - - The system tries to clear the buffers but the microcode might not support the operation. + - The processor is vulnerable but microcode is not updated. The + mitigation is enabled on a best effort basis. + + If the processor is vulnerable but the availability of the microcode + based mitigation mechanism is not advertised via CPUID, the kernel + selects a best effort mitigation mode. This mode invokes the mitigation + instructions without a guarantee that they clear the CPU buffers. + + This is done to address virtualization scenarios where the host has the + microcode update applied, but the hypervisor is not yet updated to + expose the CPUID to the guest. If the host has updated microcode the + protection takes effect; otherwise a few CPU cycles are wasted + pointlessly. * - 'Mitigation: Clear CPU buffers' - The microcode has been updated to clear the buffers. TSX is still enabled. * - 'Mitigation: TSX disabled' @@ -106,25 +118,6 @@ The possible values in this file are: * - 'Not affected' - The CPU is not affected by this issue. -.. _ucode_needed: - -Best effort mitigation mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If the processor is vulnerable, but the availability of the microcode-based -mitigation mechanism is not advertised via CPUID the kernel selects a best -effort mitigation mode. This mode invokes the mitigation instructions -without a guarantee that they clear the CPU buffers. - -This is done to address virtualization scenarios where the host has the -microcode update applied, but the hypervisor is not yet updated to expose the -CPUID to the guest. If the host has updated microcode the protection takes -effect; otherwise a few CPU cycles are wasted pointlessly. - -The state in the tsx_async_abort sysfs file reflects this situation -accordingly. - - Mitigation mechanism -------------------- -- cgit From d17ff438a0366f9dcd764ea94c54837873f30724 Mon Sep 17 00:00:00 2001 From: Vratislav Bendel Date: Mon, 29 Aug 2022 14:46:38 +0200 Subject: docs: mm: fix vm overcommit documentation for OVERCOMMIT_GUESS Commit 8c7829b04c52 "mm: fix false-positive OVERCOMMIT_GUESS failures" changed the behavior of the default OVERCOMMIT_GUESS setting. Reflect the change also in the Documentation, namely files: Documentation/admin-guide/sysctl/vm.rst Documentation/mm/overcommit-accounting.rst Reported-by: Jozef Bacik Signed-off-by: Vratislav Bendel Acked-by: Mike Rapoport Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20220829124638.63748-1-vbendel@redhat.com --- Documentation/admin-guide/sysctl/vm.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation/admin-guide') diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 45ba1f4dc004..c59889de122b 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -742,8 +742,8 @@ overcommit_memory This value contains a flag that enables memory overcommitment. -When this flag is 0, the kernel attempts to estimate the amount -of free memory left when userspace requests more memory. +When this flag is 0, the kernel compares the userspace memory request +size against total memory plus swap and rejects obvious overcommits. When this flag is 1, the kernel pretends there is always enough memory until it actually runs out. -- cgit From 2087f270bebb78adc5059fd040e2691cd7f9bb5c Mon Sep 17 00:00:00 2001 From: Amos Wenger Date: Fri, 6 Oct 2023 13:26:36 +0200 Subject: mm/memory-hotplug: fix typo in documentation I'm 90% sure memory hotunplugging doesn't involve a "fist" phase Signed-off-by: Amos Wenger Reviewed-by: David Hildenbrand Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20231006112636.97128-1-amos@bearcove.net --- Documentation/admin-guide/mm/memory-hotplug.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/admin-guide') diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index 01595965734a..aa50b8501c2e 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -75,7 +75,7 @@ Memory hotunplug consists of two phases: (1) Offlining memory blocks (2) Removing the memory from Linux -In the fist phase, memory is "hidden" from the page allocator again, for +In the first phase, memory is "hidden" from the page allocator again, for example, by migrating busy memory to other memory locations and removing all relevant free pages from the page allocator After this phase, the memory is no longer visible in memory statistics of the system. -- cgit From a10874e8db9421731bb2bb26ada4412043494471 Mon Sep 17 00:00:00 2001 From: Jade Lovelace Date: Thu, 19 Oct 2023 16:16:55 -0700 Subject: Documentation: fix typo in dynamic-debug howto Signed-off-by: Jade Lovelace Signed-off-by: Jonathan Corbet Message-ID: <20231019231655.3162225-1-lists@jade.fyi> --- Documentation/admin-guide/dynamic-debug-howto.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/admin-guide') diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 0b3d39c610d9..0c526dac8428 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -259,7 +259,7 @@ Debug Messages at Module Initialization Time When ``modprobe foo`` is called, modprobe scans ``/proc/cmdline`` for ``foo.params``, strips ``foo.``, and passes them to the kernel along with -params given in modprobe args or ``/etc/modprob.d/*.conf`` files, +params given in modprobe args or ``/etc/modprobe.d/*.conf`` files, in the following order: 1. parameters given via ``/etc/modprobe.d/*.conf``:: -- cgit From c1081a7b16abc80af7048672dcae1d3b57b6f257 Mon Sep 17 00:00:00 2001 From: Tang Yizhou Date: Thu, 12 Oct 2023 10:42:28 +0800 Subject: doc: blk-ioprio: Bring the doc in line with the implementation Our system administrator have noted that the names 'rt-to-be' and 'all-to-idle' in the I/O priority policies table appeared without explanations, leading to confusion. Let's bring these names in line with the naming in the 'attribute' section. Additionally, 1. Correct the interface name to 'io.prio.class'. 2. Add a table entry of 'promote-to-rt' for consistency. 3. Fix a typo of 'priority'. Suggested-by: Yingfu Zhou Reviewed-by: Hou Tao Signed-off-by: Tang Yizhou Reviewed-by: Bart Van Assche Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20231012024228.2161283-1-yizhou.tang@shopee.com --- Documentation/admin-guide/cgroup-v2.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'Documentation/admin-guide') diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index b26b5274eaaf..cfbc0a748ef9 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -2023,7 +2023,7 @@ IO Priority ~~~~~~~~~~~ A single attribute controls the behavior of the I/O priority cgroup policy, -namely the blkio.prio.class attribute. The following values are accepted for +namely the io.prio.class attribute. The following values are accepted for that attribute: no-change @@ -2052,9 +2052,11 @@ The following numerical values are associated with the I/O priority policies: +----------------+---+ | no-change | 0 | +----------------+---+ -| rt-to-be | 2 | +| promote-to-rt | 1 | +----------------+---+ -| all-to-idle | 3 | +| restrict-to-be | 2 | ++----------------+---+ +| idle | 3 | +----------------+---+ The numerical value that corresponds to each I/O priority class is as follows: @@ -2074,7 +2076,7 @@ The algorithm to set the I/O priority class for a request is as follows: - If I/O priority class policy is promote-to-rt, change the request I/O priority class to IOPRIO_CLASS_RT and change the request I/O priority level to 4. -- If I/O priorityt class is not promote-to-rt, translate the I/O priority +- If I/O priority class policy is not promote-to-rt, translate the I/O priority class policy into a number, then change the request I/O priority class into the maximum of the I/O priority class policy number and the numerical I/O priority class. -- cgit From 07d87ceaecdde1835866d6acd0e1c1e08500ec82 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Fri, 20 Oct 2023 20:10:59 +0200 Subject: speakup: Document USB support Speakup has been supporting USB for a while already. Signed-off-by: Samuel Thibault Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20231020181059.7rtj2csi7t6vorrm@begin --- Documentation/admin-guide/spkguide.txt | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) (limited to 'Documentation/admin-guide') diff --git a/Documentation/admin-guide/spkguide.txt b/Documentation/admin-guide/spkguide.txt index 74ea7f391942..0d5965138f8f 100644 --- a/Documentation/admin-guide/spkguide.txt +++ b/Documentation/admin-guide/spkguide.txt @@ -7,7 +7,7 @@ Last modified on Mon Sep 27 14:26:31 2010 Document version 1.3 Copyright (c) 2005 Gene Collins -Copyright (c) 2008 Samuel Thibault +Copyright (c) 2008, 2023 Samuel Thibault Copyright (c) 2009, 2010 the Speakup Team Permission is granted to copy, distribute and/or modify this document @@ -83,8 +83,7 @@ spkout -- Speak Out txprt -- Transport dummy -- Plain text terminal -Note: Speakup does * NOT * support usb connections! Speakup also does * -NOT * support the internal Tripletalk! +Note: Speakup does * NOT * support the internal Tripletalk! Speakup does support two other synthesizers, but because they work in conjunction with other software, they must be loaded as modules after @@ -94,6 +93,12 @@ These are as follows: decpc -- DecTalk PC (not available at boot up) soft -- One of several software synthesizers (not available at boot up) +By default speakup looks for the synthesizer on the ttyS0 serial port. This can +be changed with the device parameter of the modules, for instance for +DoubleTalk LT: + +speakup_ltlk.dev=ttyUSB0 + See the sections on loading modules and software synthesizers later in this manual for further details. It should be noted here that the speakup.synth boot parameter will have no effect if Speakup has been -- cgit