Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

Documentation: Fix typos

Fix typos in Documentation.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230814212822.193684-4-helgaas@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

authored by

Bjorn Helgaas and committed by
Jonathan Corbet
d56b699d ebab9426

+194 -194
+1 -1
Documentation/admin-guide/kernel-parameters.txt
··· 2624 2624 2625 2625 kvm-intel.flexpriority= 2626 2626 [KVM,Intel] Control KVM's use of FlexPriority feature 2627 - (TPR shadow). Default is 1 (enabled). Disalbe by KVM if 2627 + (TPR shadow). Default is 1 (enabled). Disable by KVM if 2628 2628 hardware lacks support for it. 2629 2629 2630 2630 kvm-intel.nested=
+2 -2
Documentation/admin-guide/mm/damon/usage.rst
··· 99 99 100 100 The root of the DAMON sysfs interface is ``<sysfs>/kernel/mm/damon/``, and it 101 101 has one directory named ``admin``. The directory contains the files for 102 - privileged user space programs' control of DAMON. User space tools or deamons 102 + privileged user space programs' control of DAMON. User space tools or daemons 103 103 having the root permission could use this directory. 104 104 105 105 kdamonds/ ··· 397 397 The statistics can be retrieved by reading the files under ``stats`` directory 398 398 (``nr_tried``, ``sz_tried``, ``nr_applied``, ``sz_applied``, and 399 399 ``qt_exceeds``), respectively. The files are not updated in real time, so you 400 - should ask DAMON sysfs interface to updte the content of the files for the 400 + should ask DAMON sysfs interface to update the content of the files for the 401 401 stats by writing a special keyword, ``update_schemes_stats`` to the relevant 402 402 ``kdamonds/<N>/state`` file. 403 403
+1 -1
Documentation/admin-guide/module-signing.rst
··· 266 266 unsigned. Any module for which the kernel has a key, but which proves to have 267 267 a signature mismatch will not be permitted to load. 268 268 269 - Any module that has an unparseable signature will be rejected. 269 + Any module that has an unparsable signature will be rejected. 270 270 271 271 272 272 =========================================
+1 -1
Documentation/arch/arm/arm.rst
··· 141 141 `*configure` harddrive set to 2). I've got an internal 20MB and a great 142 142 big external 5.25" FH 64MB drive (who could ever want more :-) ). 143 143 144 - I've just got 240K/s off it (a dd with bs=128k); thats about half of what 144 + I've just got 240K/s off it (a dd with bs=128k); that's about half of what 145 145 RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting 146 146 last week :-) 147 147
+2 -2
Documentation/arch/arm/ixp4xx.rst
··· 78 78 1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB). 79 79 To access PCI via this space, we simply ioremap() the BAR 80 80 into the kernel and we can use the standard read[bwl]/write[bwl] 81 - macros. This is the preffered method due to speed but it 81 + macros. This is the preferred method due to speed but it 82 82 limits the system to just 64MB of PCI memory. This can be 83 - problamatic if using video cards and other memory-heavy devices. 83 + problematic if using video cards and other memory-heavy devices. 84 84 85 85 2) If > 64MB of memory space is required, the IXP4xx can be 86 86 configured to use indirect registers to access PCI This allows
+1 -1
Documentation/arch/arm/sunxi/clocks.rst
··· 5 5 This document contains useful bits of information that people tend to ask 6 6 about the sunxi clock system, as well as accompanying ASCII art when adequate. 7 7 8 - Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the 8 + Q: Why is the main 24MHz oscillator gateable? Wouldn't that break the 9 9 system? 10 10 11 11 A: The 24MHz oscillator allows gating to save power. Indeed, if gated
+1 -1
Documentation/arch/arm/swp_emulation.rst
··· 1 1 Software emulation of deprecated SWP instruction (CONFIG_SWP_EMULATE) 2 2 --------------------------------------------------------------------- 3 3 4 - ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommeds 4 + ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommends 5 5 moving to the load-locked/store-conditional instructions LDREX and STREX. 6 6 7 7 ARMv7 multiprocessing extensions introduce the ability to disable these
+1 -1
Documentation/arch/arm/tcm.rst
··· 71 71 72 72 - Have the remaining TCM RAM added to a special 73 73 allocation pool with gen_pool_create() and gen_pool_add() 74 - and provice tcm_alloc() and tcm_free() for this 74 + and provide tcm_alloc() and tcm_free() for this 75 75 memory. Such a heap is great for things like saving 76 76 device state when shutting off device power domains. 77 77
+1 -1
Documentation/arch/arm/vlocks.rst
··· 155 155 optimisation. 156 156 157 157 If there are too many CPUs to read the currently_voting array in 158 - one transaction then multiple transations are still required. The 158 + one transaction then multiple transactions are still required. The 159 159 implementation uses a simple loop of word-sized loads for this 160 160 case. The number of transactions is still fewer than would be 161 161 required if bytes were loaded individually.
+1 -1
Documentation/arch/arm64/acpi_object_usage.rst
··· 45 45 46 46 **Arm Performance Monitoring Table** 47 47 48 - This table describes the properties of PMU support implmented by 48 + This table describes the properties of PMU support implemented by 49 49 components in the system. 50 50 51 51 BERT Section 18.3 (signature == "BERT")
+1 -1
Documentation/arch/arm64/arm-acpi.rst
··· 99 99 100 100 When a Linux driver or subsystem is first implemented using ACPI, it by 101 101 definition ends up requiring a specific version of the ACPI specification 102 - -- it's baseline. ACPI firmware must continue to work, even though it may 102 + -- its baseline. ACPI firmware must continue to work, even though it may 103 103 not be optimal, with the earliest kernel version that first provides support 104 104 for that baseline version of ACPI. There may be a need for additional drivers, 105 105 but adding new functionality (e.g., CPU power management) should not break
+2 -2
Documentation/arch/openrisc/openrisc_port.rst
··· 106 106 a much improved version with changes all around. 107 107 108 108 10-04-2004 Matjaz Breskvar (phoenix@bsemi.com) 109 - alot of bugfixes all over. 109 + a lot of bugfixes all over. 110 110 ethernet support, functional http and telnet servers. 111 111 running many standard linux apps. 112 112 ··· 114 114 port to 2.6.x 115 115 116 116 30-11-2004 Matjaz Breskvar (phoenix@bsemi.com) 117 - lots of bugfixes and enhancments. 117 + lots of bugfixes and enhancements. 118 118 added opencores framebuffer driver. 119 119 120 120 09-10-2010 Jonas Bonn (jonas@southpole.se)
+1 -1
Documentation/arch/x86/boot.rst
··· 1105 1105 code, nor should it be located in high memory. 1106 1106 1107 1107 1108 - Sample Boot Configuartion 1108 + Sample Boot Configuration 1109 1109 ========================= 1110 1110 1111 1111 As a sample configuration, assume the following layout of the real
+1 -1
Documentation/arch/x86/buslock.rst
··· 32 32 -------------------------------------- 33 33 34 34 Beginning with the Tremont Atom CPU split lock operations may raise an 35 - Alignment Check (#AC) exception when a split lock operation is attemped. 35 + Alignment Check (#AC) exception when a split lock operation is attempted. 36 36 37 37 #DB exception for bus lock detection 38 38 ------------------------------------
+1 -1
Documentation/arch/x86/mds.rst
··· 60 60 data 61 61 62 62 The existence of such a construct in the kernel cannot be excluded with 63 - 100% certainty, but the complexity involved makes it extremly unlikely. 63 + 100% certainty, but the complexity involved makes it extremely unlikely. 64 64 65 65 There is one exception, which is untrusted BPF. The functionality of 66 66 untrusted BPF is limited, but it needs to be thoroughly investigated
+1 -1
Documentation/arch/x86/sgx.rst
··· 245 245 limited. However, while this may be fatal to SGX, the rest of the kernel 246 246 is unlikely to be impacted and should continue to work. 247 247 248 - As a result, when this happpens, user should stop running any new 248 + As a result, when this happens, user should stop running any new 249 249 SGX workloads, (or just any new workloads), and migrate all valuable 250 250 workloads. Although a machine reboot can recover all EPC memory, the bug 251 251 should be reported to Linux developers.
+1 -1
Documentation/arch/xtensa/atomctl.rst
··· 23 23 operations. 24 24 25 25 For systems without an coherent cache controller, non-MX, we always 26 - use the memory controllers RCW, thought non-MX controlers likely 26 + use the memory controllers RCW, though non-MX controllers likely 27 27 support the Internal Operation. 28 28 29 29 CUSTOMER-WARNING:
+1 -1
Documentation/block/data-integrity.rst
··· 209 209 sector must be set, and the bio should have all data pages 210 210 added. It is up to the caller to ensure that the bio does not 211 211 change while I/O is in progress. 212 - Complete bio with error if prepare failed for some reson. 212 + Complete bio with error if prepare failed for some reason. 213 213 214 214 215 215 5.3 Passing Existing Integrity Metadata
+1 -1
Documentation/block/ublk.rst
··· 238 238 request of ``/dev/ublkb*``. 239 239 240 240 UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from 241 - the driver. A fixed mmaped area (array) on ``/dev/ublkc*`` is provided for 241 + the driver. A fixed mmapped area (array) on ``/dev/ublkc*`` is provided for 242 242 exporting IO info to the server; such as IO offset, length, OP/flags and 243 243 buffer address. Each ``ublksrv_io_desc`` instance can be indexed via queue id 244 244 and IO tag directly.
+1 -1
Documentation/bpf/cpumasks.rst
··· 364 364 ---- 365 365 366 366 Some example usages of these querying kfuncs were shown above. We will not 367 - replicate those exmaples here. Note, however, that all of the aforementioned 367 + replicate those examples here. Note, however, that all of the aforementioned 368 368 kfuncs are tested in `tools/testing/selftests/bpf/progs/cpumask_success.c`_, so 369 369 please take a look there if you're looking for more examples of how they can be 370 370 used.
+1 -1
Documentation/bpf/graph_ds_impl.rst
··· 23 23 24 24 The BPF map API has historically been the main way to expose data structures 25 25 of various types for use within BPF programs. Some data structures fit naturally 26 - with the map API (HASH, ARRAY), others less so. Consequentially, programs 26 + with the map API (HASH, ARRAY), others less so. Consequently, programs 27 27 interacting with the latter group of data structures can be hard to parse 28 28 for kernel programmers without previous BPF experience. 29 29
+1 -1
Documentation/fault-injection/fault-injection.rst
··· 243 243 Error Injectable Functions 244 244 -------------------------- 245 245 246 - This part is for the kenrel developers considering to add a function to 246 + This part is for the kernel developers considering to add a function to 247 247 ALLOW_ERROR_INJECTION() macro. 248 248 249 249 Requirements for the Error Injectable Functions
+1 -1
Documentation/fb/deferred_io.rst
··· 9 9 10 10 - userspace app like Xfbdev mmaps framebuffer 11 11 - deferred IO and driver sets up fault and page_mkwrite handlers 12 - - userspace app tries to write to mmaped vaddress 12 + - userspace app tries to write to mmapped vaddress 13 13 - we get pagefault and reach fault handler 14 14 - fault handler finds and returns physical page 15 15 - we get page_mkwrite where we add this page to a list
+1 -1
Documentation/fb/sm712fb.rst
··· 31 31 ================ 32 32 (alias TODO list) 33 33 34 - * 2D acceleratrion 34 + * 2D acceleration 35 35 * dual-head support
+1 -1
Documentation/fb/sstfb.rst
··· 73 73 the device will be /dev/fb0. You can check this by doing a 74 74 cat /proc/fb. You can find a copy of con2fb in tools/ directory. 75 75 if you don't have another fb device, this step is superfluous, 76 - as the console subsystem automagicaly binds ttys to the fb. 76 + as the console subsystem automagically binds ttys to the fb. 77 77 #. switch to the virtual console you just mapped. "tadaaa" ... 78 78 79 79 Module removal
+1 -1
Documentation/features/core/thread-info-in-task/arch-support.txt
··· 1 1 # 2 2 # Feature name: thread-info-in-task 3 3 # Kconfig: THREAD_INFO_IN_TASK 4 - # description: arch makes use of the core kernel facility to embedd thread_info in task_struct 4 + # description: arch makes use of the core kernel facility to embed thread_info in task_struct 5 5 # 6 6 ----------------------- 7 7 | arch |status|
+1 -1
Documentation/filesystems/9p.rst
··· 79 79 80 80 cache=mode specifies a caching policy. By default, no caches are used. 81 81 The mode can be specified as a bitmask or by using one of the 82 - prexisting common 'shortcuts'. 82 + preexisting common 'shortcuts'. 83 83 The bitmask is described below: (unspecified bits are reserved) 84 84 85 85 ========== ====================================================
+2 -2
Documentation/filesystems/befs.rst
··· 106 106 debug The driver will output debugging information to the syslog. 107 107 ============= =========================================================== 108 108 109 - How to Get Lastest Version 110 - ========================== 109 + How to Get Latest Version 110 + ========================= 111 111 112 112 The latest version is currently available at: 113 113 <http://befs-driver.sourceforge.net/>
+1 -1
Documentation/filesystems/caching/cachefiles.rst
··· 416 416 example). 417 417 418 418 The subjective security holds the active security properties of a process, and 419 - may be overridden. This is not seen externally, and is used whan a process 419 + may be overridden. This is not seen externally, and is used when a process 420 420 acts upon another object, for example SIGKILLing another process or opening a 421 421 file. 422 422
+3 -3
Documentation/filesystems/caching/netfs-api.rst
··· 59 59 60 60 The filesystem then acquires a cookie for each file within that volume using an 61 61 object key. Object keys are binary blobs and only need to be unique within 62 - their parent volume. The cache backend is reponsible for rendering the binary 62 + their parent volume. The cache backend is responsible for rendering the binary 63 63 blob into something it can use and may employ hash tables, trees or whatever to 64 64 improve its ability to find an object. This is transparent to the network 65 65 filesystem. ··· 91 91 Volume Registration 92 92 =================== 93 93 94 - The first step for a network filsystem is to acquire a volume cookie for the 94 + The first step for a network filesystem is to acquire a volume cookie for the 95 95 volume it wants to access:: 96 96 97 97 struct fscache_volume * ··· 119 119 be invalidated. 120 120 121 121 This function can return errors such as EBUSY if the volume key is already in 122 - use by an acquired volume or ENOMEM if an allocation failure occured. It may 122 + use by an acquired volume or ENOMEM if an allocation failure occurred. It may 123 123 also return a NULL volume cookie if fscache is not enabled. It is safe to 124 124 pass a NULL cookie to any function that takes a volume cookie. This will 125 125 cause that function to do nothing.
+1 -1
Documentation/filesystems/configfs.rst
··· 253 253 If binary attribute is readable and the config_item provides a 254 254 ct_item_ops->read_bin_attribute() method, that method will be called 255 255 whenever userspace asks for a read(2) on the attribute. The converse 256 - will happen for write(2). The reads/writes are bufferred so only a 256 + will happen for write(2). The reads/writes are buffered so only a 257 257 single read/write will occur; the attributes' need not concern itself 258 258 with it. 259 259
+1 -1
Documentation/filesystems/dax.rst
··· 291 291 mapped caches such as ARM, MIPS and SPARC. 292 292 293 293 Calling :c:func:`get_user_pages()` on a range of user memory that has been 294 - mmaped from a `DAX` file will fail when there are no 'struct page' to describe 294 + mmapped from a `DAX` file will fail when there are no 'struct page' to describe 295 295 those pages. This problem has been addressed in some device drivers 296 296 by adding optional struct page support for pages under the control of 297 297 the driver (see `CONFIG_NVDIMM_PFN` in ``drivers/nvdimm`` for an example of
+2 -2
Documentation/filesystems/devpts.rst
··· 5 5 ===================== 6 6 7 7 Each mount of the devpts filesystem is now distinct such that ptys 8 - and their indicies allocated in one mount are independent from ptys 9 - and their indicies in all other mounts. 8 + and their indices allocated in one mount are independent from ptys 9 + and their indices in all other mounts. 10 10 11 11 All mounts of the devpts filesystem now create a ``/dev/pts/ptmx`` node 12 12 with permissions ``0000``.
+1 -1
Documentation/filesystems/ext4/super.rst
··· 772 772 * - 0x0010 773 773 - Do not support 32-bit UIDs. (EXT4_DEFM_UID16) 774 774 * - 0x0020 775 - - All data and metadata are commited to the journal. 775 + - All data and metadata are committed to the journal. 776 776 (EXT4_DEFM_JMODE_DATA) 777 777 * - 0x0040 778 778 - All data are flushed to the disk before metadata are committed to the
+3 -3
Documentation/filesystems/f2fs.rst
··· 359 359 ====================== =============== =============== ======== 360 360 mode continue remount-ro panic 361 361 ====================== =============== =============== ======== 362 - access ops normal noraml N/A 362 + access ops normal normal N/A 363 363 syscall errors -EIO -EROFS N/A 364 364 mount option rw ro N/A 365 365 pending dir write keep keep N/A ··· 480 480 481 481 sload.f2fs 482 482 ---------- 483 - The sload.f2fs gives a way to insert files and directories in the exisiting disk 483 + The sload.f2fs gives a way to insert files and directories in the existing disk 484 484 image. This tool is useful when building f2fs images given compiled files. 485 485 486 486 Note: please refer to the manpage of sload.f2fs(8) to get full option list. ··· 792 792 as a method of optimally implementing that function. 793 793 794 794 However, once F2FS receives ioctl(fd, F2FS_IOC_SET_PIN_FILE) in prior to 795 - fallocate(fd, DEFAULT_MODE), it allocates on-disk block addressess having 795 + fallocate(fd, DEFAULT_MODE), it allocates on-disk block addresses having 796 796 zero or random data, which is useful to the below scenario where: 797 797 798 798 1. create(fd)
+1 -1
Documentation/filesystems/gfs2-glocks.rst
··· 78 78 grant for which we ignore remote demote requests. This is in order to 79 79 prevent a situation where locks are being bounced around the cluster 80 80 from node to node with none of the nodes making any progress. This 81 - tends to show up most with shared mmaped files which are being written 81 + tends to show up most with shared mmapped files which are being written 82 82 to by multiple nodes. By delaying the demotion in response to a 83 83 remote callback, that gives the userspace program time to make 84 84 some progress before the pages are unmapped.
+7 -7
Documentation/filesystems/idmappings.rst
··· 36 36 From a mathematical viewpoint ``U`` and ``K`` are well-ordered sets and an 37 37 idmapping is an order isomorphism from ``U`` into ``K``. So ``U`` and ``K`` are 38 38 order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of 39 - the set of all possible ids useable on a given system. 39 + the set of all possible ids usable on a given system. 40 40 41 41 Looking at this mathematically briefly will help us highlight some properties 42 42 that make it easier to understand how we can translate between idmappings. For ··· 47 47 k10002 -> u24 48 48 49 49 Given that we are dealing with order isomorphisms plus the fact that we're 50 - dealing with subsets we can embedd idmappings into each other, i.e. we can 50 + dealing with subsets we can embed idmappings into each other, i.e. we can 51 51 sensibly translate between different idmappings. For example, assume we've been 52 52 given the three idmappings:: 53 53 ··· 60 60 61 61 Because we're dealing with order isomorphic subsets it is meaningful to ask 62 62 what id ``k11000`` corresponds to in the second or third idmapping. The 63 - straightfoward algorithm to use is to apply the inverse of the first idmapping, 63 + straightforward algorithm to use is to apply the inverse of the first idmapping, 64 64 mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using 65 65 either the second idmapping mapping or third idmapping mapping. The second 66 66 idmapping would map ``u1000`` down to ``21000``. The third idmapping would map ··· 367 367 written to disk. If it can't the kernel will refuse the creation request to not 368 368 even remotely risk filesystem corruption. 369 369 370 - The astute reader will have realized that this is simply a varation of the 370 + The astute reader will have realized that this is simply a variation of the 371 371 crossmapping algorithm we mentioned above in a previous section. First, the 372 372 kernel maps the caller's userspace id down into a kernel id according to the 373 373 caller's idmapping and then maps that kernel id up according to the ··· 458 458 consequences. 459 459 460 460 First, that we can't allow a caller to ultimately write to disk with another 461 - userspace id. We could only do this if we were to mount the whole fileystem 461 + userspace id. We could only do this if we were to mount the whole filesystem 462 462 with the caller's or another idmapping. But that solution is limited to a few 463 463 filesystems and not very flexible. But this is a use-case that is pretty 464 464 important in containerized workloads. ··· 589 589 590 590 In both cases changing ownership recursively has grave implications. The most 591 591 obvious one is that ownership is changed globally and permanently. In the home 592 - directory case this change in ownership would even need to happen everytime the 592 + directory case this change in ownership would even need to happen every time the 593 593 user switches from their home to their work machine. For really large sets of 594 594 files this becomes increasingly costly. 595 595 ··· 662 662 To illustrate why this helper currently exists, consider what happens when we 663 663 change ownership of an inode from an idmapped mount. After we generated 664 664 a ``vfsuid_t`` or ``vfsgid_t`` based on the mount idmapping we later commit to 665 - this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesytem wide ownership. 665 + this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesystem wide ownership. 666 666 Thus, we are turning the ``vfsuid_t`` or ``vfsgid_t`` into a global ``kuid_t`` 667 667 or ``kgid_t``. And this can be done by using ``vfsuid_into_kuid()`` and 668 668 ``vfsgid_into_kgid()``.
+1 -1
Documentation/filesystems/netfs_library.rst
··· 155 155 an error occurs after calling the helper. 156 156 157 157 The helpers manage the read request, calling back into the network filesystem 158 - through the suppplied table of operations. Waits will be performed as 158 + through the supplied table of operations. Waits will be performed as 159 159 necessary before returning for helpers that are meant to be synchronous. 160 160 161 161 If an error occurs, the ->free_request() will be called to clean up the
+1 -1
Documentation/filesystems/nfs/client-identifier.rst
··· 131 131 the node name by itself is not adequately unique, and can change 132 132 unexpectedly. Problematic situations include: 133 133 134 - - NFS-root (diskless) clients, where the local DCHP server (or 134 + - NFS-root (diskless) clients, where the local DHCP server (or 135 135 equivalent) does not provide a unique host name. 136 136 137 137 - "Containers" within a single Linux host. If each container has
+1 -1
Documentation/filesystems/nfs/rpc-cache.rst
··· 78 78 include taking references to shared objects. 79 79 80 80 void update(struct cache_head \*orig, struct cache_head \*new) 81 - Set the 'content' fileds in 'new' from 'orig'. 81 + Set the 'content' fields in 'new' from 'orig'. 82 82 83 83 int cache_show(struct seq_file \*m, struct cache_detail \*cd, struct cache_head \*h) 84 84 Optional. Used to provide a /proc file that lists the
+1 -1
Documentation/filesystems/nfs/rpc-server-gss.rst
··· 29 29 depends on GSSAPI extensions that are KRB5 specific. 30 30 31 31 GSSAPI is a complex library, and implementing it completely in kernel is 32 - unwarranted. However GSSAPI operations are fundementally separable in 2 32 + unwarranted. However GSSAPI operations are fundamentally separable in 2 33 33 parts: 34 34 35 35 - initial context establishment
+1 -1
Documentation/filesystems/nilfs2.rst
··· 231 231 232 232 233 233 The logs include regular files, directory files, symbolic link files 234 - and several meta data files. The mata data files are the files used 234 + and several meta data files. The meta data files are the files used 235 235 to maintain file system meta data. The current version of NILFS2 uses 236 236 the following meta data files:: 237 237
+1 -1
Documentation/filesystems/ntfs3.rst
··· 112 112 Todo list 113 113 ========= 114 114 - Full journaling support over JBD. Currently journal replaying is supported 115 - which is not necessarily as effectice as JBD would be. 115 + which is not necessarily as effective as JBD would be. 116 116 117 117 References 118 118 ==========
+1 -1
Documentation/filesystems/orangefs.rst
··· 274 274 of kcalloced memory. This memory is used as an array of pointers 275 275 to each of the pages in the IO buffer through a call to get_user_pages. 276 276 * desc_array - a pointer to ``desc_count * (sizeof(struct orangefs_bufmap_desc))`` 277 - bytes of kcalloced memory. This memory is further intialized: 277 + bytes of kcalloced memory. This memory is further initialized: 278 278 279 279 user_desc is the kernel's copy of the IO buffer's ORANGEFS_dev_map_desc 280 280 structure. user_desc->ptr points to the IO buffer.
+2 -2
Documentation/filesystems/overlayfs.rst
··· 195 195 196 196 1. return EXDEV error: this error is returned by rename(2) when trying to 197 197 move a file or directory across filesystem boundaries. Hence 198 - applications are usually prepared to hande this error (mv(1) for example 198 + applications are usually prepared to handle this error (mv(1) for example 199 199 recursively copies the directory tree). This is the default behavior. 200 200 201 201 2. If the "redirect_dir" feature is enabled, then the directory will be ··· 235 235 Redirects are not created and not followed. 236 236 - "redirect_dir=off": 237 237 If "redirect_always_follow" is enabled in the kernel/module config, 238 - this "off" traslates to "follow", otherwise it translates to "nofollow". 238 + this "off" translates to "follow", otherwise it translates to "nofollow". 239 239 240 240 When the NFS export feature is enabled, every copied up directory is 241 241 indexed by the file handle of the lower inode and a file handle of the
+3 -3
Documentation/filesystems/porting.rst
··· 177 177 **mandatory** 178 178 179 179 s_export_op is now required for exporting a filesystem. 180 - isofs, ext2, ext3, resierfs, fat 180 + isofs, ext2, ext3, reiserfs, fat 181 181 can be used as examples of very different filesystems. 182 182 183 183 --- ··· 470 470 **mandatory** 471 471 472 472 If you implement your own ->llseek() you must handle SEEK_HOLE and 473 - SEEK_DATA. You can hanle this by returning -EINVAL, but it would be nicer to 473 + SEEK_DATA. You can handle this by returning -EINVAL, but it would be nicer to 474 474 support it in some way. The generic handler assumes that the entire file is 475 475 data and there is a virtual hole at the end of the file. So if the provided 476 476 offset is less than i_size and SEEK_DATA is specified, return the same offset. ··· 517 517 518 518 ->create() doesn't take ``struct nameidata *``; unlike the previous 519 519 two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that 520 - local filesystems can ignore tha argument - they are guaranteed that the 520 + local filesystems can ignore this argument - they are guaranteed that the 521 521 object doesn't exist. It's remote/distributed ones that might care... 522 522 523 523 ---
+6 -6
Documentation/filesystems/proc.rst
··· 507 507 be lower than the real value due to optimizations used in the current 508 508 implementation. If this is not desirable please file a bug report. 509 509 510 - "AnonHugePages" shows the ammount of memory backed by transparent hugepage. 510 + "AnonHugePages" shows the amount of memory backed by transparent hugepage. 511 511 512 - "ShmemPmdMapped" shows the ammount of shared (shmem/tmpfs) memory backed by 512 + "ShmemPmdMapped" shows the amount of shared (shmem/tmpfs) memory backed by 513 513 huge pages. 514 514 515 - "Shared_Hugetlb" and "Private_Hugetlb" show the ammounts of memory backed by 515 + "Shared_Hugetlb" and "Private_Hugetlb" show the amounts of memory backed by 516 516 hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical 517 517 reasons. And these are not included in {Shared,Private}_{Clean,Dirty} field. 518 518 ··· 561 561 mm mixed map area 562 562 hg huge page advise flag 563 563 nh no huge page advise flag 564 - mg mergable advise flag 564 + mg mergeable advise flag 565 565 bt arm64 BTI guarded page 566 566 mt arm64 MTE allocation tags are enabled 567 567 um userfaultfd missing tracking ··· 1081 1081 AnonPages 1082 1082 Non-file backed pages mapped into userspace page tables 1083 1083 Mapped 1084 - files which have been mmaped, such as libraries 1084 + files which have been mmapped, such as libraries 1085 1085 Shmem 1086 1086 Total memory used by shared memory (shmem) and tmpfs 1087 1087 KReclaimable ··· 2229 2229 Chapter 5: Filesystem behavior 2230 2230 ============================== 2231 2231 2232 - Originally, before the advent of pid namepsace, procfs was a global file 2232 + Originally, before the advent of pid namespace, procfs was a global file 2233 2233 system. It means that there was only one procfs instance in the system. 2234 2234 2235 2235 When pid namespace was added, a separate procfs instance was mounted in
+1 -1
Documentation/filesystems/qnx6.rst
··· 135 135 136 136 Character and block special devices do not exist in QNX as those files 137 137 are handled by the QNX kernel/drivers and created in /dev independent of the 138 - underlaying filesystem. 138 + underlying filesystem. 139 139 140 140 Long filenames 141 141 --------------
+2 -2
Documentation/filesystems/seq_file.rst
··· 130 130 show() function (described below) to print a header at the top of the 131 131 output. SEQ_START_TOKEN should only be used if the offset is zero, 132 132 however. SEQ_START_TOKEN has no special meaning to the core seq_file 133 - code. It is provided as a convenience for a start() funciton to 133 + code. It is provided as a convenience for a start() function to 134 134 communicate with the next() and show() functions. 135 135 136 136 The next function to implement is called, amazingly, next(); its job is to ··· 217 217 is a reasonable thing to do. The seq_file code will also avoid taking any 218 218 other locks while the iterator is active. 219 219 220 - The iterater value returned by start() or next() is guaranteed to be 220 + The iterator value returned by start() or next() is guaranteed to be 221 221 passed to a subsequent next() or stop() call. This allows resources 222 222 such as locks that were taken to be reliably released. There is *no* 223 223 guarantee that the iterator will be passed to show(), though in practice
+1 -1
Documentation/filesystems/ubifs-authentication.rst
··· 130 130 Journal 131 131 ~~~~~~~ 132 132 133 - To avoid wearing out the flash, the index is only persisted (*commited*) when 133 + To avoid wearing out the flash, the index is only persisted (*committed*) when 134 134 certain conditions are met (eg. ``fsync(2)``). The journal is used to record 135 135 any changes (in form of inode nodes, data nodes etc.) between commits 136 136 of the index. During mount, the journal is read from the flash and replayed
+1 -1
Documentation/filesystems/vfat.rst
··· 50 50 Normally utime(2) checks current process is owner of 51 51 the file, or it has CAP_FOWNER capability. But FAT 52 52 filesystem doesn't have uid/gid on disk, so normal 53 - check is too unflexible. With this option you can 53 + check is too inflexible. With this option you can 54 54 relax it. 55 55 56 56 **codepage=###**
+1 -1
Documentation/filesystems/vfs.rst
··· 761 761 a file sync request is made. After an error has been reported on one 762 762 request, subsequent requests on the same file descriptor should return 763 763 0, unless further writeback errors have occurred since the previous file 764 - syncronization. 764 + synchronization. 765 765 766 766 Ideally, the kernel would report errors only on file descriptions on 767 767 which writes were done that subsequently failed to be written back. The
+10 -10
Documentation/filesystems/xfs-online-fsck-design.rst
··· 293 293 Before starting repairs, the summary counters are checked and any necessary 294 294 repairs are performed so that subsequent repairs will not fail the resource 295 295 reservation step due to wildly incorrect summary counters. 296 - Unsuccesful repairs are requeued as long as forward progress on repairs is 296 + Unsuccessful repairs are requeued as long as forward progress on repairs is 297 297 made somewhere in the filesystem. 298 298 Free space in the filesystem is trimmed at the end of phase 4 if the 299 299 filesystem is clean. ··· 542 542 543 543 Inspiration for quota and file link count repair strategies were drawn from 544 544 sections 2.12 ("Online Index Operations") through 2.14 ("Incremental View 545 - Maintenace") of G. Graefe, `"Concurrent Queries and Updates in Summary Views 545 + Maintenance") of G. Graefe, `"Concurrent Queries and Updates in Summary Views 546 546 and Their Indexes" 547 547 <http://www.odbms.org/wp-content/uploads/2014/06/Increment-locks.pdf>`_, 2011. 548 548 ··· 605 605 The cron job does not have this protection. 606 606 607 607 - **Fuzz Kiddiez**: There are many people now who seem to think that running 608 - automated fuzz testing of ondisk artifacts to find mischevious behavior and 608 + automated fuzz testing of ondisk artifacts to find mischievous behavior and 609 609 spraying exploit code onto the public mailing list for instant zero-day 610 610 disclosure is somehow of some social benefit. 611 611 In the view of this author, the benefit is realized only when the fuzz ··· 1351 1351 rooted at block 0) is created to map hashes of the attribute names to leaf 1352 1352 blocks in the attr fork. 1353 1353 1354 - Checking an extended attribute structure is not so straightfoward due to the 1354 + Checking an extended attribute structure is not so straightforward due to the 1355 1355 lack of separation between attr blocks and index blocks. 1356 1356 Scrub must read each block mapped by the attr fork and ignore the non-leaf 1357 1357 blocks: ··· 1401 1401 beyond one block, then a dabtree is used to map hashes of dirent names to 1402 1402 directory data blocks. 1403 1403 1404 - Checking a directory is pretty straightfoward: 1404 + Checking a directory is pretty straightforward: 1405 1405 1406 1406 1. Walk the dabtree in the second partition (if present) to ensure that there 1407 1407 are no irregularities in the blocks or dabtree mappings that do not point to ··· 1524 1524 should be relatively rare as compared to filesystem change operations. 1525 1525 Online fsck coordinates with transaction chains as follows: 1526 1526 1527 - * For each AG, maintain a count of intent items targetting that AG. 1527 + * For each AG, maintain a count of intent items targeting that AG. 1528 1528 The count should be bumped whenever a new item is added to the chain. 1529 1529 The count should be dropped when the filesystem has locked the AG header 1530 1530 buffers and finished the work. ··· 2102 2102 kernel. 2103 2103 To sort records in a reasonably short amount of time, ``xfarray`` takes 2104 2104 advantage of the binary subpartitioning offered by quicksort, but it also uses 2105 - heapsort to hedge aginst performance collapse if the chosen quicksort pivots 2105 + heapsort to hedge against performance collapse if the chosen quicksort pivots 2106 2106 are poor. 2107 2107 Both algorithms are (in general) O(n * lg(n)), but there is a wide performance 2108 2108 gulf between the two implementations. ··· 2566 2566 The transaction rolling in steps 2c and 3 represent a weakness in the repair 2567 2567 algorithm, because a log flush and a crash before the end of the reap step can 2568 2568 result in space leaking. 2569 - Online repair functions minimize the chances of this occuring by using very 2570 - large transactions, which each can accomodate many thousands of block freeing 2569 + Online repair functions minimize the chances of this occurring by using very 2570 + large transactions, which each can accommodate many thousands of block freeing 2571 2571 instructions. 2572 2572 Repair moves on to reaping the old blocks, which will be presented in a 2573 2573 subsequent :ref:`section<reaping>` after a few case studies of bulk loading. ··· 5090 5090 counters) as phase 6. 5091 5091 The scan starts by calling ``FS_IOC_GETFSMAP`` to scan the filesystem space map 5092 5092 to find areas that are allocated to file data fork extents. 5093 - Gaps betweeen data fork extents that are smaller than 64k are treated as if 5093 + Gaps between data fork extents that are smaller than 64k are treated as if 5094 5094 they were data fork extents to reduce the command setup overhead. 5095 5095 When the space map scan accumulates a region larger than 32MB, a media 5096 5096 verification request is sent to the disk as a directio read of the raw block
+1 -1
Documentation/filesystems/zonefs.rst
··· 378 378 sequential zone files. Failure to do so can result in write errors. 379 379 * **max_active_seq_files**: This attribute reports the maximum number of 380 380 sequential zone files that are in an active state, that is, sequential zone 381 - files that are partially writen (not empty nor full) or that have a zone that 381 + files that are partially written (not empty nor full) or that have a zone that 382 382 is explicitly open (which happens only if the *explicit-open* mount option is 383 383 used). This number is always equal to the maximum number of active zones that 384 384 the device supports. A value of 0 means that the mounted device has no limit
+1 -1
Documentation/firmware-guide/acpi/osi.rst
··· 55 55 56 56 However this was discovered to be abused by other BIOS vendors to change 57 57 completely unrelated code on completely unrelated systems. This prompted 58 - an evaluation of all of it's uses. This uncovered that they aren't needed 58 + an evaluation of all of its uses. This uncovered that they aren't needed 59 59 for any of the original reasons. As such, the kernel will not respond to 60 60 any custom Linux-* strings by default. 61 61
+1 -1
Documentation/gpu/amdgpu/display/mpo-overview.rst
··· 178 178 179 179 AMDGPU supports display MPO when using multiple displays; however, this feature 180 180 behavior heavily relies on the compositor implementation. Keep in mind that 181 - usespace can define different policies. For example, some OSes can use MPO to 181 + userspace can define different policies. For example, some OSes can use MPO to 182 182 protect the plane that handles the video playback; notice that we don't have 183 183 many limitations for a single display. Nonetheless, this manipulation can have 184 184 many more restrictions for a multi-display scenario. The below example shows a
+1 -1
Documentation/gpu/drm-kms-helpers.rst
··· 378 378 HDMI Infoframes Helper Reference 379 379 ================================ 380 380 381 - Strictly speaking this is not a DRM helper library but generally useable 381 + Strictly speaking this is not a DRM helper library but generally usable 382 382 by any driver interfacing with HDMI outputs like v4l or alsa drivers. 383 383 But it nicely fits into the overall topic of mode setting helper 384 384 libraries and hence is also included here.
+3 -3
Documentation/gpu/drm-kms.rst
··· 66 66 For the output routing the first step is encoders (represented by 67 67 :c:type:`struct drm_encoder <drm_encoder>`, see `Encoder Abstraction`_). Those 68 68 are really just internal artifacts of the helper libraries used to implement KMS 69 - drivers. Besides that they make it unecessarily more complicated for userspace 69 + drivers. Besides that they make it unnecessarily more complicated for userspace 70 70 to figure out which connections between a CRTC and a connector are possible, and 71 71 what kind of cloning is supported, they serve no purpose in the userspace API. 72 72 Unfortunately encoders have been exposed to userspace, hence can't remove them 73 - at this point. Futhermore the exposed restrictions are often wrongly set by 73 + at this point. Furthermore the exposed restrictions are often wrongly set by 74 74 drivers, and in many cases not powerful enough to express the real restrictions. 75 75 A CRTC can be connected to multiple encoders, and for an active CRTC there must 76 76 be at least one encoder. ··· 260 260 drm_crtc_state <drm_crtc_state>` for CRTCs and :c:type:`struct 261 261 drm_connector_state <drm_connector_state>` for connectors. These are the only 262 262 objects with userspace-visible and settable state. For internal state drivers 263 - can subclass these structures through embeddeding, or add entirely new state 263 + can subclass these structures through embedding, or add entirely new state 264 264 structures for their globally shared hardware functions, see :c:type:`struct 265 265 drm_private_state<drm_private_state>`. 266 266
+2 -2
Documentation/gpu/drm-usage-stats.rst
··· 8 8 `fops->show_fdinfo()` as part of the driver specific file operations registered 9 9 in the `struct drm_driver` object registered with the DRM core. 10 10 11 - One purpose of this output is to enable writing as generic as practicaly 11 + One purpose of this output is to enable writing as generic as practically 12 12 feasible `top(1)` like userspace monitoring tools. 13 13 14 14 Given the differences between various DRM drivers the specification of the ··· 119 119 engine. Taken together with drm-cycles-<keystr>, this can be used to calculate 120 120 percentage utilization of the engine, whereas drm-engine-<keystr> only reflects 121 121 time active without considering what frequency the engine is operating as a 122 - percentage of it's maximum frequency. 122 + percentage of its maximum frequency. 123 123 124 124 Memory 125 125 ^^^^^^
+2 -2
Documentation/gpu/i915.rst
··· 304 304 and the only way to synchronize across contexts (even from the same 305 305 file descriptor) is through the use of fences. At least as far back as 306 306 Gen4, also have that a context carries with it a GPU HW context; 307 - the HW context is essentially (most of atleast) the state of a GPU. 307 + the HW context is essentially (most of at least) the state of a GPU. 308 308 In addition to the ordering guarantees, the kernel will restore GPU 309 309 state via HW context when commands are issued to a context, this saves 310 - user space the need to restore (most of atleast) the GPU state at the 310 + user space the need to restore (most of at least) the GPU state at the 311 311 start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer 312 312 work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) 313 313 to identify what context to use with the command.
+1 -1
Documentation/gpu/kms-properties.csv
··· 17 17 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector 18 18 ,,“suggested Y”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector 19 19 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB 20 - i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normaly in the range 0..1.0 are remapped to the range 16/255..235/255." 20 + i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normally in the range 0..1.0 are remapped to the range 16/255..235/255." 21 21 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD 22 22 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD 23 23 ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
+2 -2
Documentation/gpu/komeda-kms.rst
··· 328 328 achieve this, split the komeda device into two layers: CORE and CHIP. 329 329 330 330 - CORE: for common features and capabilities handling. 331 - - CHIP: for register programing and HW specific feature (limitation) handling. 331 + - CHIP: for register programming and HW specific feature (limitation) handling. 332 332 333 333 CORE can access CHIP by three chip function structures: 334 334 ··· 481 481 Now we have two level devices: 482 482 483 483 - komeda_dev: describes the real display hardware. 484 - - komeda_kms_dev: attachs or connects komeda_dev to DRM-KMS. 484 + - komeda_kms_dev: attaches or connects komeda_dev to DRM-KMS. 485 485 486 486 All komeda operations are supplied or operated by komeda_dev or komeda_kms_dev, 487 487 the module driver is only a simple wrapper to pass the Linux command
+1 -1
Documentation/gpu/msm-crash-dump.rst
··· 23 23 The module that generated the crashdump. 24 24 25 25 time 26 - The kernel time at crash formated as seconds.microseconds. 26 + The kernel time at crash formatted as seconds.microseconds. 27 27 28 28 comm 29 29 Comm string for the binary that generated the fault.
+1 -1
Documentation/gpu/rfc/i915_scheduler.rst
··· 37 37 * Watchdog hooks into DRM scheduler 38 38 * Lots of complexity of the GuC backend can be pulled out once 39 39 integrated with DRM scheduler (e.g. state machine gets 40 - simplier, locking gets simplier, etc...) 40 + simpler, locking gets simpler, etc...) 41 41 * Execlists backend will minimum required to hook in the DRM scheduler 42 42 * Legacy interface 43 43 * Features like timeslicing / preemption / virtual engines would
+1 -1
Documentation/gpu/rfc/i915_vm_bind.rst
··· 90 90 path (where required mappings are already bound) submission latency is O(1) 91 91 w.r.t the number of VM private BOs. 92 92 93 - VM_BIND locking hirarchy 93 + VM_BIND locking hierarchy 94 94 ------------------------- 95 95 The locking design here supports the older (execlist based) execbuf mode, the 96 96 newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future
+4 -4
Documentation/gpu/todo.rst
··· 65 65 --------------------------------------------------------- 66 66 67 67 We have a helper to get this right with drm_plane_helper_check_update(), but 68 - it's not consistently used. This should be fixed, preferrably in the atomic 68 + it's not consistently used. This should be fixed, preferably in the atomic 69 69 helpers (and drivers then moved over to clipped coordinates). Probably the 70 70 helper should also be moved from drm_plane_helper.c to the atomic helpers, to 71 71 avoid confusion - the other helpers in that file are all deprecated legacy ··· 181 181 182 182 To solve this we need one standard per-object locking mechanism, which is 183 183 dma_resv_lock(). This lock needs to be called as the outermost lock, with all 184 - other driver specific per-object locks removed. The problem is tha rolling out 184 + other driver specific per-object locks removed. The problem is that rolling out 185 185 the actual change to the locking contract is a flag day, due to struct dma_buf 186 186 buffer sharing. 187 187 188 188 Level: Expert 189 189 190 - Convert logging to drm_* functions with drm_device paramater 190 + Convert logging to drm_* functions with drm_device parameter 191 191 ------------------------------------------------------------ 192 192 193 193 For drivers which could have multiple instances, it is necessary to ··· 244 244 Benchmark and optimize blitting and format-conversion function 245 245 -------------------------------------------------------------- 246 246 247 - Drawing to dispay memory quickly is crucial for many applications' 247 + Drawing to display memory quickly is crucial for many applications' 248 248 performance. 249 249 250 250 On at least x86-64, sys_imageblit() is significantly slower than
+1 -1
Documentation/hwmon/pmbus-core.rst
··· 345 345 346 346 Some PMBus chips don't respond with valid data when reading the CAPABILITY 347 347 register. For such chips, this flag should be set so that the PMBus core 348 - driver doesn't use CAPABILITY to determine it's behavior. 348 + driver doesn't use CAPABILITY to determine its behavior. 349 349 350 350 PMBUS_READ_STATUS_AFTER_FAILED_CHECK 351 351
+1 -1
Documentation/input/devices/iforce-protocol.rst
··· 49 49 == ==== 50 50 51 51 The 2B, LEN and CS fields have disappeared, probably because USB handles 52 - frames and data corruption is handled or unsignificant. 52 + frames and data corruption is handled or insignificant. 53 53 54 54 First, I describe effects that are sent by the device to the computer 55 55
+1 -1
Documentation/input/multi-touch-protocol.rst
··· 383 383 --------------- 384 384 385 385 The process of finger tracking, i.e., to assign a unique trackingID to each 386 - initiated contact on the surface, is a Euclidian Bipartite Matching 386 + initiated contact on the surface, is a Euclidean Bipartite Matching 387 387 problem. At each event synchronization, the set of actual contacts is 388 388 matched to the set of contacts from the previous synchronization. A full 389 389 implementation can be found in [#f3]_.
+1 -1
Documentation/livepatch/reliable-stacktrace.rst
··· 40 40 .. note:: 41 41 In some cases it is legitimate to omit specific functions from the trace, 42 42 but all other functions must be reported. These cases are described in 43 - futher detail below. 43 + further detail below. 44 44 45 45 Secondly, the reliable stacktrace function must be robust to cases where 46 46 the stack or other unwind state is corrupt or otherwise unreliable. The
+2 -2
Documentation/locking/lockdep-design.rst
··· 29 29 A lock-class's behavior is constructed by its instances collectively: 30 30 when the first instance of a lock-class is used after bootup the class 31 31 gets registered, then all (subsequent) instances will be mapped to the 32 - class and hence their usages and dependecies will contribute to those of 32 + class and hence their usages and dependencies will contribute to those of 33 33 the class. A lock-class does not go away when a lock instance does, but 34 34 it can be removed if the memory space of the lock class (static or 35 35 dynamic) is reclaimed, this happens for example when a module is ··· 105 105 +--------------+-------------+--------------+ 106 106 107 107 The character '-' suggests irq is disabled because if otherwise the 108 - charactor '?' would have been shown instead. Similar deduction can be 108 + character '?' would have been shown instead. Similar deduction can be 109 109 applied for '+' too. 110 110 111 111 Unused locks (e.g., mutexes) cannot be part of the cause of an error.
+1 -1
Documentation/locking/locktorture.rst
··· 113 113 without pausing. 114 114 115 115 shuffle_interval 116 - The number of seconds to keep the test threads affinitied 116 + The number of seconds to keep the test threads affinitized 117 117 to a particular subset of the CPUs, defaults to 3 seconds. 118 118 Used in conjunction with test_no_idle_hz. 119 119
+1 -1
Documentation/locking/locktypes.rst
··· 500 500 Some bit spinlocks are replaced with regular spinlock_t for PREEMPT_RT 501 501 using conditional (#ifdef'ed) code changes at the usage site. In contrast, 502 502 usage-site changes are not needed for the spinlock_t substitution. 503 - Instead, conditionals in header files and the core locking implemementation 503 + Instead, conditionals in header files and the core locking implementation 504 504 enable the compiler to do the substitution transparently. 505 505 506 506
+1 -1
Documentation/mm/hmm.rst
··· 417 417 resovled by replacing the entry with the original mapping. A driver gets 418 418 notified that the mapping has been changed by MMU notifiers, after which point 419 419 it will no longer have exclusive access to the page. Exclusive access is 420 - guranteed to last until the driver drops the page lock and page reference, at 420 + guaranteed to last until the driver drops the page lock and page reference, at 421 421 which point any CPU faults on the page may proceed as described. 422 422 423 423 Memory cgroup (memcg) and rss accounting
+1 -1
Documentation/mm/hwpoison.rst
··· 48 48 For the KVM use there was need for a new signal type so that 49 49 KVM can inject the machine check into the guest with the proper 50 50 address. This in theory allows other applications to handle 51 - memory failures too. The expection is that near all applications 51 + memory failures too. The expectation is that most applications 52 52 won't do that, but some very specialized ones might. 53 53 54 54 Failure recovery modes
+1 -1
Documentation/mm/page_migration.rst
··· 180 180 4. THP_MIGRATION_FAIL: A THP could not be migrated nor it could be split. 181 181 182 182 5. THP_MIGRATION_SPLIT: A THP was migrated, but not as such: first, the THP had 183 - to be split. After splitting, a migration retry was used for it's sub-pages. 183 + to be split. After splitting, a migration retry was used for its sub-pages. 184 184 185 185 THP_MIGRATION_* events also update the appropriate PGMIGRATE_SUCCESS or 186 186 PGMIGRATE_FAIL events. For example, a THP migration failure will cause both
+1 -1
Documentation/mm/unevictable-lru.rst
··· 463 463 to the mmap() call. There is one important and subtle difference here, though. 464 464 mmap() + mlock() will fail if the range cannot be faulted in (e.g. because 465 465 mm_populate fails) and returns with ENOMEM while mmap(MAP_LOCKED) will not fail. 466 - The mmaped area will still have properties of the locked area - pages will not 466 + The mmapped area will still have properties of the locked area - pages will not 467 467 get swapped out - but major page faults to fault memory in might still happen. 468 468 469 469 Furthermore, any mmap() call or brk() call that expands the heap by a task
+1 -1
Documentation/mm/vmemmap_dedup.rst
··· 11 11 This section is to explain how HugeTLB Vmemmap Optimization (HVO) works. 12 12 13 13 The ``struct page`` structures are used to describe a physical page frame. By 14 - default, there is a one-to-one mapping from a page frame to it's corresponding 14 + default, there is a one-to-one mapping from a page frame to its corresponding 15 15 ``struct page``. 16 16 17 17 HugeTLB pages consist of multiple base page size pages and is supported by many
+1 -1
Documentation/networking/bonding.rst
··· 1636 1636 ----------------------------------------- 1637 1637 1638 1638 This section applies to distros which use /etc/network/interfaces file 1639 - to describe network interface configuration, most notably Debian and it's 1639 + to describe network interface configuration, most notably Debian and its 1640 1640 derivatives. 1641 1641 1642 1642 The ifup and ifdown commands on Debian don't support bonding out of
+1 -1
Documentation/networking/packet_mmap.rst
··· 755 755 ============================ 756 756 757 757 AF_PACKET's TPACKET_V3 ring buffer can be configured to use non-static frame 758 - sizes by doing it's own memory management. It is based on blocks where polling 758 + sizes by doing its own memory management. It is based on blocks where polling 759 759 works on a per block basis instead of per ring as in TPACKET_V2 and predecessor. 760 760 761 761 It is said that TPACKET_V3 brings the following benefits:
+2 -2
Documentation/power/energy-model.rst
··· 87 87 Registration of 'advanced' EM 88 88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89 89 90 - The 'advanced' EM gets it's name due to the fact that the driver is allowed 90 + The 'advanced' EM gets its name due to the fact that the driver is allowed 91 91 to provide more precised power model. It's not limited to some implemented math 92 - formula in the framework (like it's in 'simple' EM case). It can better reflect 92 + formula in the framework (like it is in 'simple' EM case). It can better reflect 93 93 the real power measurements performed for each performance state. Thus, this 94 94 registration method should be preferred in case considering EM static power 95 95 (leakage) is important.
+1 -1
Documentation/powerpc/dscr.rst
··· 6 6 stream in the processor. Please refer to the ISA documents or related manual 7 7 for more detailed information regarding how to use this DSCR to attain this 8 8 control of the prefetches . This document here provides an overview of kernel 9 - support for DSCR, related kernel objects, it's functionalities and exported 9 + support for DSCR, related kernel objects, its functionalities and exported 10 10 user interface. 11 11 12 12 (A) Data Structures:
+1 -1
Documentation/powerpc/kasan.txt
··· 40 40 instrument any code that runs with translations off after booting. This is the 41 41 current approach. 42 42 43 - To avoid this limitiation, the KASAN shadow would have to be placed inside the 43 + To avoid this limitation, the KASAN shadow would have to be placed inside the 44 44 linear mapping, using the same high-bits trick we use for the rest of the linear 45 45 mapping. This is tricky: 46 46
+1 -1
Documentation/powerpc/papr_hcalls.rst
··· 22 22 On PPC64 arch a guest kernel running on top of a PAPR hypervisor is called 23 23 a *pSeries guest*. A pseries guest runs in a supervisor mode (HV=0) and must 24 24 issue hypercalls to the hypervisor whenever it needs to perform an action 25 - that is hypervisor priviledged [3]_ or for other services managed by the 25 + that is hypervisor privileged [3]_ or for other services managed by the 26 26 hypervisor. 27 27 28 28 Hence a Hypercall (hcall) is essentially a request by the pseries guest
+2 -2
Documentation/powerpc/qe_firmware.rst
··· 232 232 'extended_modes' is a bitfield that defines special functionality which has an 233 233 impact on the device drivers. Each bit has its own impact and has special 234 234 instructions for the driver associated with it. This field is stored in 235 - the QE library and available to any driver that calles qe_get_firmware_info(). 235 + the QE library and available to any driver that calls qe_get_firmware_info(). 236 236 237 237 'vtraps' is an array of 8 words that contain virtual trap values for each 238 238 virtual traps. As with 'extended_modes', this field is stored in the QE 239 - library and available to any driver that calles qe_get_firmware_info(). 239 + library and available to any driver that calls qe_get_firmware_info(). 240 240 241 241 'microcode' (type: struct qe_microcode): 242 242 For each RISC processor there is one 'microcode' structure. The first
+2 -2
Documentation/powerpc/vas-api.rst
··· 46 46 The application can then submit one or more requests to the engine by 47 47 using copy/paste instructions and pasting the CRBs to the virtual address 48 48 (aka paste_address) returned by mmap(). User space can close the 49 - established connection or send window by closing the file descriptior 49 + established connection or send window by closing the file descriptor 50 50 (close(fd)) or upon the process exit. 51 51 52 52 Note that applications can send several requests with the same window or ··· 240 240 siginfo.si_signo = SIGSEGV; 241 241 siginfo.si_errno = EFAULT; 242 242 siginfo.si_code = SEGV_MAPERR; 243 - siginfo.si_addr = CSB adress; 243 + siginfo.si_addr = CSB address; 244 244 245 245 In the case of multi-thread applications, NX send windows can be shared 246 246 across all threads. For example, a child thread can open a send window,
+1 -1
Documentation/process/botching-up-ioctls.rst
··· 208 208 it's much quicker to push a driver-private interface than engaging in 209 209 lengthy discussions for a more generic solution. And occasionally doing a 210 210 private interface to spearhead a new concept is what's required. But in the 211 - end, once the generic interface comes around you'll end up maintainer two 211 + end, once the generic interface comes around you'll end up maintaining two 212 212 interfaces. Indefinitely. 213 213 214 214 * Consider other interfaces than ioctls. A sysfs attribute is much better for
+1 -1
Documentation/process/kernel-docs.rst
··· 29 29 30 30 The documents on each section of this document are ordered by its 31 31 published date, from the newest to the oldest. The maintainer(s) should 32 - periodically retire resources as they become obsolte or outdated; with 32 + periodically retire resources as they become obsolete or outdated; with 33 33 the exception of foundational books. 34 34 35 35 Docs at the Linux Kernel tree
+2 -2
Documentation/riscv/hwprobe.rst
··· 88 88 always extremely slow. 89 89 90 90 * :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are supported 91 - in hardware, but are slower than the cooresponding aligned accesses 91 + in hardware, but are slower than the corresponding aligned accesses 92 92 sequences. 93 93 94 94 * :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are supported 95 - in hardware and are faster than the cooresponding aligned accesses 95 + in hardware and are faster than the corresponding aligned accesses 96 96 sequences. 97 97 98 98 * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
+1 -1
Documentation/riscv/vector.rst
··· 13 13 Two new prctl() calls are added to allow programs to manage the enablement 14 14 status for the use of Vector in userspace. The intended usage guideline for 15 15 these interfaces is to give init systems a way to modify the availability of V 16 - for processes running under its domain. Calling thess interfaces is not 16 + for processes running under its domain. Calling these interfaces is not 17 17 recommended in libraries routines because libraries should not override policies 18 18 configured from the parant process. Also, users must noted that these interfaces 19 19 are not portable to non-Linux, nor non-RISC-V environments, so it is discourage
+1 -1
Documentation/s390/vfio-ap.rst
··· 422 422 Configuring the AP resources for a KVM guest will be performed when the 423 423 VFIO_GROUP_NOTIFY_SET_KVM notifier callback is invoked. The notifier 424 424 function is called when userspace connects to KVM. The guest's AP resources are 425 - configured via it's APCB by: 425 + configured via its APCB by: 426 426 427 427 * Setting the bits in the APM corresponding to the APIDs assigned to the 428 428 vfio_ap mediated device via its 'assign_adapter' interface.
+1 -1
Documentation/scheduler/sched-bwc.rst
··· 186 186 also limits the burst ability to no more than 1ms per cpu. This provides 187 187 better more predictable user experience for highly threaded applications with 188 188 small quota limits on high core count machines. It also eliminates the 189 - propensity to throttle these applications while simultanously using less than 189 + propensity to throttle these applications while simultaneously using less than 190 190 quota amounts of cpu. Another way to say this, is that by allowing the unused 191 191 portion of a slice to remain valid across periods we have decreased the 192 192 possibility of wastefully expiring quota on cpu-local silos that don't need a
+2 -2
Documentation/scheduler/sched-energy.rst
··· 82 82 The rest of platform knowledge used by EAS is directly read from the Energy 83 83 Model (EM) framework. The EM of a platform is composed of a power cost table 84 84 per 'performance domain' in the system (see Documentation/power/energy-model.rst 85 - for futher details about performance domains). 85 + for further details about performance domains). 86 86 87 87 The scheduler manages references to the EM objects in the topology code when the 88 88 scheduling domains are built, or re-built. For each root domain (rd), the ··· 281 281 From a general standpoint, the use-cases where EAS can help the most are those 282 282 involving a light/medium CPU utilization. Whenever long CPU-bound tasks are 283 283 being run, they will require all of the available CPU capacity, and there isn't 284 - much that can be done by the scheduler to save energy without severly harming 284 + much that can be done by the scheduler to save energy without severely harming 285 285 throughput. In order to avoid hurting performance with EAS, CPUs are flagged as 286 286 'over-utilized' as soon as they are used at more than 80% of their compute 287 287 capacity. As long as no CPUs are over-utilized in a root domain, load balancing
+1 -1
Documentation/scsi/ChangeLog.lpfc
··· 427 427 * Changed version number to 8.0.17 428 428 * Fix sparse warnings by adding __iomem markers to lpfc_compat.h. 429 429 * Fix some sparse warnings -- 0 used as NULL pointer. 430 - * Make sure there's a space between every if and it's (. 430 + * Make sure there's a space between every if and its (. 431 431 * Fix some overly long lines and make sure hard tabs are used for 432 432 indentation. 433 433 * Remove all trailing whitespace.
+1 -1
Documentation/security/digsig.rst
··· 82 82 to generate signatures, to load keys into the kernel keyring. 83 83 Keys can be in PEM or converted to the kernel format. 84 84 When the key is added to the kernel keyring, the keyid defines the name 85 - of the key: 5D2B05FC633EE3E8 in the example bellow. 85 + of the key: 5D2B05FC633EE3E8 in the example below. 86 86 87 87 Here is example output of the keyctl utility:: 88 88
+1 -1
Documentation/security/keys/core.rst
··· 869 869 870 870 - ``char *hashname`` specifies the NUL terminated string identifying 871 871 the hash used from the kernel crypto API and applied for the KDF 872 - operation. The KDF implemenation complies with SP800-56A as well 872 + operation. The KDF implementation complies with SP800-56A as well 873 873 as with SP800-108 (the counter KDF). 874 874 875 875 - ``char *otherinfo`` specifies the OtherInfo data as documented in
+1 -1
Documentation/security/secrets/coco.rst
··· 34 34 35 35 During the VM's launch, the virtual machine manager may inject a secret to that 36 36 area. In AMD SEV and SEV-ES this is performed using the 37 - ``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The strucutre of the injected 37 + ``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The structure of the injected 38 38 Guest Owner secret data should be a GUIDed table of secret values; the binary 39 39 format is described in ``drivers/virt/coco/efi_secret/efi_secret.c`` under 40 40 "Structure of the EFI secret area".
+1 -1
Documentation/sphinx/cdomain.py
··· 178 178 if len(arglist[0].split(" ")) > 1: 179 179 return False 180 180 181 - # This is a function-like macro, it's arguments are typeless! 181 + # This is a function-like macro, its arguments are typeless! 182 182 signode += addnodes.desc_name(fullname, fullname) 183 183 paramlist = addnodes.desc_parameterlist() 184 184 signode += paramlist
+1 -1
Documentation/spi/spi-lm70llp.rst
··· 69 69 and not grounded by the host via D7), the transistor conducts and switches 70 70 the collector to zero, which is reflected on pin 13 of the DB25 parport 71 71 connector. When SI/O is Low (driven by the LM70 or the host) on the other 72 - hand, the transistor is cut off and the voltage tied to it's collector is 72 + hand, the transistor is cut off and the voltage tied to its collector is 73 73 reflected on pin 13 as a High level. 74 74 75 75 So: the getmiso inline routine in this driver takes this fact into account,
+1 -1
Documentation/tools/rtla/rtla-timerlat-top.rst
··· 117 117 The raw trace is saved in the **timerlat_trace.txt** file for further analysis. 118 118 119 119 Note that **rtla timerlat** was dispatched without changing *timerlat* tracer 120 - threads' priority. That is generally not needed because these threads hava 120 + threads' priority. That is generally not needed because these threads have 121 121 priority *FIFO:95* by default, which is a common priority used by real-time 122 122 kernel developers to analyze scheduling delays. 123 123
+1 -1
Documentation/trace/coresight/coresight-etm4x-reference.rst
··· 675 675 reconstructed using only conditional branches. 676 676 677 677 There is currently no support in Perf for supplying modified binaries to the decoder, so this 678 - feature is only inteded to be used for debugging purposes or with a 3rd party tool. 678 + feature is only intended to be used for debugging purposes or with a 3rd party tool. 679 679 680 680 Choosing this option will result in a significant increase in the amount of trace generated - 681 681 possible danger of overflows, or fewer instructions covered. Note, that this option also
+3 -3
Documentation/trace/events.rst
··· 915 915 916 916 To create a kprobe event, an empty or partially empty kprobe event 917 917 should first be created using kprobe_event_gen_cmd_start(). The name 918 - of the event and the probe location should be specfied along with one 918 + of the event and the probe location should be specified along with one 919 919 or args each representing a probe field should be supplied to this 920 920 function. Before calling kprobe_event_gen_cmd_start(), the user 921 921 should create and initialize a dynevent_cmd object using ··· 995 995 layer that can be used to generate trace event commands. The 996 996 generated command strings can then be passed to the command-parsing 997 997 and event creation code that already exists in the trace event 998 - subystem for creating the corresponding trace events. 998 + subsystem for creating the corresponding trace events. 999 999 1000 1000 In a nutshell, the way it works is that the higher-level interface 1001 1001 code creates a struct dynevent_cmd object, then uses a couple ··· 1068 1068 appended onto the end of the arg pair (here ';'). 1069 1069 1070 1070 There's also a dynevent_str_add() function that can be used to simply 1071 - add a string as-is, with no spaces, delimeters, or arg check. 1071 + add a string as-is, with no spaces, delimiters, or arg check. 1072 1072 1073 1073 Any number of dynevent_*_add() calls can be made to build up the string 1074 1074 (until its length surpasses cmd->maxlen). When all the arguments have
+1 -1
Documentation/trace/fprobe.rst
··· 113 113 the instruction pointer of @regs may be different from the @entry_ip 114 114 in the entry_handler. If you need traced instruction pointer, you need 115 115 to use @entry_ip. On the other hand, in the exit_handler, the instruction 116 - pointer of @regs is set to the currect return address. 116 + pointer of @regs is set to the current return address. 117 117 118 118 @entry_data 119 119 This is a local storage to share the data between entry and exit handlers.
+1 -1
Documentation/trace/ftrace.rst
··· 2725 2725 2726 2726 The return value of each traced function can be displayed after 2727 2727 an equal sign "=". When encountering system call failures, it 2728 - can be verfy helpful to quickly locate the function that first 2728 + can be very helpful to quickly locate the function that first 2729 2729 returns an error code. 2730 2730 2731 2731 - hide: echo nofuncgraph-retval > trace_options
+1 -1
Documentation/trace/hwlat_detector.rst
··· 14 14 kernel is highly latency sensitive. 15 15 16 16 SMIs are not serviced by the Linux kernel, which means that it does not 17 - even know that they are occuring. SMIs are instead set up by BIOS code 17 + even know that they are occurring. SMIs are instead set up by BIOS code 18 18 and are serviced by BIOS code, usually for "critical" events such as 19 19 management of thermal sensors and fans. Sometimes though, SMIs are used for 20 20 other tasks and those tasks can spend an inordinate amount of time in the
+1 -1
Documentation/trace/rv/da_monitor_synthesis.rst
··· 1 1 Deterministic Automata Monitor Synthesis 2 2 ======================================== 3 3 4 - The starting point for the application of runtime verification (RV) technics 4 + The starting point for the application of runtime verification (RV) techniques 5 5 is the *specification* or *modeling* of the desired (or undesired) behavior 6 6 of the system under scrutiny. 7 7
+1 -1
Documentation/trace/rv/monitor_wwnr.rst
··· 26 26 | running | -+ 27 27 +-------------+ 28 28 29 - This model is borken, the reason is that a task can be running 29 + This model is broken, the reason is that a task can be running 30 30 in the processor without being set as RUNNABLE. Think about a 31 31 task about to sleep:: 32 32
+1 -1
Documentation/trace/rv/runtime-verification.rst
··· 31 31 *RV monitor* abstraction. A *RV monitor* includes a reference model of the 32 32 system, a set of instances of the monitor (per-cpu monitor, per-task monitor, 33 33 and so on), and the helper functions that glue the monitor to the system via 34 - trace, as depicted bellow:: 34 + trace, as depicted below:: 35 35 36 36 Linux +---- RV Monitor ----------------------------------+ Formal 37 37 Realm | | Realm
+1 -1
Documentation/trace/uprobetracer.rst
··· 55 55 56 56 (\*1) only for return probe. 57 57 (\*2) this is useful for fetching a field of data structures. 58 - (\*3) Unlike kprobe event, "u" prefix will just be ignored, becuse uprobe 58 + (\*3) Unlike kprobe event, "u" prefix will just be ignored, because uprobe 59 59 events can access only user-space memory. 60 60 61 61 Types
+1 -1
Documentation/trace/user_events.rst
··· 93 93 94 94 **NOTE:** The event subsystem name by default is "user_events". Callers should 95 95 not assume it will always be "user_events". Operators reserve the right in the 96 - future to change the subsystem name per-process to accomodate event isolation. 96 + future to change the subsystem name per-process to accommodate event isolation. 97 97 98 98 Command Format 99 99 ^^^^^^^^^^^^^^
+1 -1
Documentation/usb/gadget_uvc.rst
··· 168 168 169 169 The UVC specification requires that Format and Frame descriptors be preceded by 170 170 Headers detailing things such as the number and cumulative size of the different 171 - Format descriptors that follow. This and similar operations are acheived in 171 + Format descriptors that follow. This and similar operations are achieved in 172 172 configfs by linking between the configfs item representing the header and the 173 173 config items representing those other descriptors, in this manner: 174 174
+1 -1
Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
··· 3293 3293 3294 3294 .. c:type:: v4l2_av1_loop_restoration 3295 3295 3296 - AV1 Loop Restauration as described in section 6.10.15 "Loop restoration params 3296 + AV1 Loop Restoration as described in section 6.10.15 "Loop restoration params 3297 3297 semantics" of :ref:`av1`. 3298 3298 3299 3299 .. cssclass:: longtable
+1 -1
Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
··· 237 237 camera projectors. As we have another field for "Laser Power" we introduced 238 238 "LED Power" for extra emitter. 239 239 240 - The "Laser mode" __u32 fiels has been split into: :: 240 + The "Laser mode" __u32 fields has been split into: :: 241 241 1 __u8 Emitter mode 242 242 2 __u8 RFU byte 243 243 3 __u16 LED Power
+1 -1
Documentation/userspace-api/netlink/intro.rst
··· 615 615 is defined by the 2 lowest bits of the message type, so commands for 616 616 new objects would always be allocated with a stride of 4. 617 617 618 - Each object would also have it's own fixed metadata shared by all request 618 + Each object would also have its own fixed metadata shared by all request 619 619 types (e.g. struct ifinfomsg for netdev requests, struct ifaddrmsg for address 620 620 requests, struct tcmsg for qdisc requests). 621 621
+1 -1
Documentation/virt/hyperv/clocks.rst
··· 60 60 entirely in user space. The vDSO is implemented by mapping the 61 61 shared page with scale and offset values into user space. User 62 62 space code performs the same algorithm of reading the TSC and 63 - appying the scale and offset to get the constant 10 MHz clock. 63 + applying the scale and offset to get the constant 10 MHz clock. 64 64 65 65 Linux clockevents are based on Hyper-V synthetic timer 0. While 66 66 Hyper-V offers 4 synthetic timers for each CPU, Linux only uses
+13 -13
Documentation/virt/kvm/api.rst
··· 578 578 RISC-V: 579 579 ^^^^^^^ 580 580 581 - Queues an external interrupt to be injected into the virutal CPU. This ioctl 581 + Queues an external interrupt to be injected into the virtual CPU. This ioctl 582 582 is overloaded with 2 different irq values: 583 583 584 584 a) KVM_INTERRUPT_SET ··· 2722 2722 a Guest VCPU runs. It will have ISA feature bits matching underlying host 2723 2723 set by default. 2724 2724 2725 - RISC-V core registers represent the general excution state of a Guest VCPU 2725 + RISC-V core registers represent the general execution state of a Guest VCPU 2726 2726 and it has the following id bit patterns:: 2727 2727 2728 2728 0x8020 0000 02 <index into the kvm_riscv_core struct:24> (32bit Host) ··· 5232 5232 Deregister the VM from the Ultravisor and reclaim the memory that had 5233 5233 been donated to the Ultravisor, making it usable by the kernel again. 5234 5234 All registered VCPUs are converted back to non-protected ones. If a 5235 - previous protected VM had been prepared for asynchonous teardown with 5235 + previous protected VM had been prepared for asynchronous teardown with 5236 5236 KVM_PV_ASYNC_CLEANUP_PREPARE and not subsequently torn down with 5237 5237 KVM_PV_ASYNC_CLEANUP_PERFORM, it will be torn down in this call 5238 5238 together with the current protected VM. ··· 5692 5692 5693 5693 ``KVM_SREGS2_FLAGS_PDPTRS_VALID`` 5694 5694 5695 - Indicates thats the struct contain valid PDPTR values. 5695 + Indicates that the struct contains valid PDPTR values. 5696 5696 5697 5697 5698 5698 4.132 KVM_SET_SREGS2 ··· 6263 6263 6264 6264 It is strongly recommended that userspace use ``KVM_EXIT_IO`` (x86) or 6265 6265 ``KVM_EXIT_MMIO`` (all except s390) to implement functionality that 6266 - requires a guest to interact with host userpace. 6266 + requires a guest to interact with host userspace. 6267 6267 6268 6268 .. note:: KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO. 6269 6269 ··· 6336 6336 } s390_ucontrol; 6337 6337 6338 6338 s390 specific. A page fault has occurred for a user controlled virtual 6339 - machine (KVM_VM_S390_UNCONTROL) on it's host page table that cannot be 6339 + machine (KVM_VM_S390_UNCONTROL) on its host page table that cannot be 6340 6340 resolved by the kernel. 6341 6341 The program code and the translation exception code that were placed 6342 6342 in the cpu's lowcore are presented here as defined by the z Architecture ··· 7510 7510 attribute is not supported by KVM. 7511 7511 7512 7512 KVM_CAP_SGX_ATTRIBUTE enables a userspace VMM to grant a VM access to one or 7513 - more priveleged enclave attributes. args[0] must hold a file handle to a valid 7513 + more privileged enclave attributes. args[0] must hold a file handle to a valid 7514 7514 SGX attribute file corresponding to an attribute that is supported/restricted 7515 7515 by KVM (currently only PROVISIONKEY). 7516 7516 ··· 7928 7928 7929 7929 This capability indicates that userspace can load HV_X64_MSR_VP_INDEX msr. Its 7930 7930 value is used to denote the target vcpu for a SynIC interrupt. For 7931 - compatibilty, KVM initializes this msr to KVM's internal vcpu index. When this 7931 + compatibility, KVM initializes this msr to KVM's internal vcpu index. When this 7932 7932 capability is absent, userspace can still query this msr's value. 7933 7933 7934 7934 8.13 KVM_CAP_S390_AIS_MIGRATION ··· 8118 8118 :Parameters: args[0] - size of the dirty log ring 8119 8119 8120 8120 KVM is capable of tracking dirty memory using ring buffers that are 8121 - mmaped into userspace; there is one dirty ring per vcpu. 8121 + mmapped into userspace; there is one dirty ring per vcpu. 8122 8122 8123 8123 The dirty ring is available to userspace as an array of 8124 - ``struct kvm_dirty_gfn``. Each dirty entry it's defined as:: 8124 + ``struct kvm_dirty_gfn``. Each dirty entry is defined as:: 8125 8125 8126 8126 struct kvm_dirty_gfn { 8127 8127 __u32 flags; ··· 8160 8160 | | 8161 8161 +------------------------------------------+ 8162 8162 8163 - To harvest the dirty pages, userspace accesses the mmaped ring buffer 8163 + To harvest the dirty pages, userspace accesses the mmapped ring buffer 8164 8164 to read the dirty GFNs. If the flags has the DIRTY bit set (at this stage 8165 8165 the RESET bit must be cleared), then it means this GFN is a dirty GFN. 8166 8166 The userspace should harvest this GFN and mark the flags from state ··· 8286 8286 and KVM_XEN_GET_ATTR ioctls. This controls whether KVM will set the 8287 8287 XEN_RUNSTATE_UPDATE flag in guest memory mapped vcpu_runstate_info during 8288 8288 updates of the runstate information. Note that versions of KVM which support 8289 - the RUNSTATE feature above, but not thie RUNSTATE_UPDATE_FLAG feature, will 8289 + the RUNSTATE feature above, but not the RUNSTATE_UPDATE_FLAG feature, will 8290 8290 always set the XEN_RUNSTATE_UPDATE flag when updating the guest structure, 8291 8291 which is perhaps counterintuitive. When this flag is advertised, KVM will 8292 8292 behave more correctly, not using the XEN_RUNSTATE_UPDATE flag until/unless ··· 8335 8335 8336 8336 When enabled, KVM will disable emulated Hyper-V features provided to the 8337 8337 guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all 8338 - currently implmented Hyper-V features are provided unconditionally when 8338 + currently implemented Hyper-V features are provided unconditionally when 8339 8339 Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001) 8340 8340 leaf. 8341 8341
+1 -1
Documentation/virt/kvm/devices/vm.rst
··· 92 92 KVM does not enforce or limit the cpu model data in any form. Take the information 93 93 retrieved by means of KVM_S390_VM_CPU_MACHINE as hint for reasonable configuration 94 94 setups. Instruction interceptions triggered by additionally set facility bits that 95 - are not handled by KVM need to by imlemented in the VM driver code. 95 + are not handled by KVM need to by implemented in the VM driver code. 96 96 97 97 :Parameters: address of buffer to store/set the processor related cpu 98 98 data of type struct kvm_s390_vm_cpu_processor*.
+1 -1
Documentation/virt/kvm/devices/xive.rst
··· 50 50 51 51 When a device is passed-through into the guest, the source 52 52 interrupts are from a different HW controller (PHB4) and the ESB 53 - pages exposed to the guest should accommadate this change. 53 + pages exposed to the guest should accommodate this change. 54 54 55 55 The passthru_irq helpers, kvmppc_xive_set_mapped() and 56 56 kvmppc_xive_clr_mapped() are called when the device HW irqs are
+1 -1
Documentation/virt/kvm/halt-polling.rst
··· 14 14 Polling provides a latency advantage in cases where the guest can be run again 15 15 very quickly by at least saving us a trip through the scheduler, normally on 16 16 the order of a few micro-seconds, although performance benefits are workload 17 - dependant. In the event that no wakeup source arrives during the polling 17 + dependent. In the event that no wakeup source arrives during the polling 18 18 interval or some other task on the runqueue is runnable the scheduler is 19 19 invoked. Thus halt polling is especially useful on workloads with very short 20 20 wakeup periods where the time spent halt polling is minimised and the time
+1 -1
Documentation/virt/kvm/x86/mmu.rst
··· 245 245 unsynchronized children). 246 246 unsync_child_bitmap: 247 247 A bitmap indicating which sptes in spt point (directly or indirectly) at 248 - pages that may be unsynchronized. Used to quickly locate all unsychronized 248 + pages that may be unsynchronized. Used to quickly locate all unsynchronized 249 249 pages reachable from a given page. 250 250 clear_spte_count: 251 251 Only present on 32-bit hosts, where a 64-bit spte cannot be written
+1 -1
Documentation/virt/kvm/x86/running-nested-guests.rst
··· 169 169 $ modprobe kvm nested=1 170 170 171 171 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive 172 - with the ``nested`` paramter — i.e. to be able to enable 172 + with the ``nested`` parameter — i.e. to be able to enable 173 173 ``nested``, the ``hpage`` parameter *must* be disabled. 174 174 175 175 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
+1 -1
Documentation/virt/uml/user_mode_linux_howto_v2.rst
··· 1224 1224 security-wise. Allowing it as a loadable module parameter 1225 1225 isn't. 1226 1226 1227 - If such functionality is desireable for a particular application 1227 + If such functionality is desirable for a particular application 1228 1228 (e.g. loading BPF "firmware" for raw socket network transports), 1229 1229 it should be off by default and should be explicitly turned on 1230 1230 as a command line parameter at startup.
+1 -1
Documentation/w1/slaves/w1_therm.rst
··· 58 58 59 59 ``conv_time`` is used to get current conversion time (read), and 60 60 adjust it (write). A temperature conversion time depends on the device type and 61 - it's current resolution. Default conversion time is set by the driver according 61 + its current resolution. Default conversion time is set by the driver according 62 62 to the device datasheet. A conversion time for many original device clones 63 63 deviate from datasheet specs. There are three options: 1) manually set the 64 64 correct conversion time by writing a value in milliseconds to ``conv_time``; 2)
+1 -1
Documentation/w1/w1-generic.rst
··· 101 101 w1_master_slave_count (ro) the number of slaves found 102 102 w1_master_slaves (ro) the names of the slaves, one per line 103 103 w1_master_timeout (ro) the delay in seconds between searches 104 - w1_master_timeout_us (ro) the delay in microseconds beetwen searches 104 + w1_master_timeout_us (ro) the delay in microseconds between searches 105 105 ========================= ===================================================== 106 106 107 107 If you have a w1 bus that never changes (you don't add or remove devices),
+1 -1
Documentation/w1/w1-netlink.rst
··· 66 66 zero or more attached w1_netlink_cmd messages. 67 67 68 68 For event messages there are no w1_netlink_cmd embedded structures, 69 - only connector header and w1_netlink_msg strucutre with "len" field 69 + only connector header and w1_netlink_msg structure with "len" field 70 70 being zero and filled type (one of event types) and id: 71 71 either 8 bytes of slave unique id in host order, 72 72 or master's id, which is assigned to bus master device
+1 -1
Documentation/watchdog/watchdog-kernel-api.rst
··· 77 77 * groups: List of sysfs attribute groups to create when creating the watchdog 78 78 device. 79 79 * info: a pointer to a watchdog_info structure. This structure gives some 80 - additional information about the watchdog timer itself. (Like it's unique name) 80 + additional information about the watchdog timer itself. (Like its unique name) 81 81 * ops: a pointer to the list of watchdog operations that the watchdog supports. 82 82 * gov: a pointer to the assigned watchdog device pretimeout governor or NULL. 83 83 * timeout: the watchdog timer's timeout value (in seconds).
+2 -2
Documentation/wmi/devices/dell-wmi-ddv.rst
··· 185 185 WMI method BatteryeRawAnalytics() 186 186 --------------------------------- 187 187 188 - Returns a buffer usually containg 12 blocks of analytics data. 188 + Returns a buffer usually containing 12 blocks of analytics data. 189 189 Those blocks contain: 190 190 - block number starting with 0 (u8) 191 191 - 31 bytes of unknown data ··· 217 217 WMI method FanSensorInformation() 218 218 --------------------------------- 219 219 220 - Returns a buffer containg fan sensor entries, terminated 220 + Returns a buffer containing fan sensor entries, terminated 221 221 with a single ``0xff``. 222 222 Those entries contain: 223 223