diff --git a/Documentation/admin-guide/laptops/toshiba_haps.rst b/Documentation/admin-guide/laptops/toshiba_haps.rst index d28b6c3..0226225 100644 --- a/Documentation/admin-guide/laptops/toshiba_haps.rst +++ b/Documentation/admin-guide/laptops/toshiba_haps.rst @@ -43,7 +43,7 @@ RSSS Shuts down the HDD protection interface for a few seconds, ==== ===================================================================== Note: - The presence of Solid State Drives (SSD) can make this driver to fail loading, + The presence of Solid State Drives (SSD) can cause this driver to fail loading, given the fact that such drives have no movable parts, and thus, not requiring any "protection" as well as failing during the evaluation of the _STA method found under this device. diff --git a/Documentation/core-api/rbtree.rst b/Documentation/core-api/rbtree.rst index ed1a9fb..cce80e1 100644 --- a/Documentation/core-api/rbtree.rst +++ b/Documentation/core-api/rbtree.rst @@ -197,7 +197,7 @@ Cached rbtrees -------------- Computing the leftmost (smallest) node is quite a common task for binary -search trees, such as for traversals or users relying on a the particular +search trees, such as for traversals or users relying on the particular order for their own logic. To this end, users can use 'struct rb_root_cached' to optimize O(logN) rb_first() calls to a simple pointer fetch avoiding potentially expensive tree iterations. This is done at negligible runtime @@ -255,7 +255,7 @@ affected subtrees. When erasing a node, the user must call rb_erase_augmented() instead of rb_erase(). rb_erase_augmented() calls back into user provided functions -to updated the augmented information on affected subtrees. +to update the augmented information on affected subtrees. In both cases, the callbacks are provided through struct rb_augment_callbacks. 3 callbacks must be defined: @@ -293,7 +293,7 @@ way making it possible to do efficient lookup and exact match. This "extra information" stored in each node is the maximum hi (max_hi) value among all the nodes that are its descendants. This -information can be maintained at each node just be looking at the node +information can be maintained at each node just by looking at the node and its immediate children. And this will be used in O(log n) lookup for lowest match (lowest start address among all possible matches) with something like:: diff --git a/Documentation/mm/page_tables.rst b/Documentation/mm/page_tables.rst index e7c69cc..126c876 100644 --- a/Documentation/mm/page_tables.rst +++ b/Documentation/mm/page_tables.rst @@ -26,9 +26,9 @@ Physical memory address 0 will be *pfn 0* and the highest pfn will be the last page of physical memory the external address bus of the CPU can address. -With a page granularity of 4KB and a address range of 32 bits, pfn 0 is at +With a page granularity of 4KB and an address range of 32 bits, pfn 0 is at address 0x00000000, pfn 1 is at address 0x00001000, pfn 2 is at 0x00002000 -and so on until we reach pfn 0xfffff at 0xfffff000. With 16KB pages pfs are +and so on until we reach pfn 0xfffff at 0xfffff000. With 16KB pages pfns are at 0x00004000, 0x00008000 ... 0xffffc000 and pfn goes from 0 to 0x3ffff. As you can see, with 4KB pages the page base address uses bits 12-31 of the @@ -38,8 +38,8 @@ address, and this is why `PAGE_SHIFT` in this case is defined as 12 and Over time a deeper hierarchy has been developed in response to increasing memory sizes. When Linux was created, 4KB pages and a single page table called `swapper_pg_dir` with 1024 entries was used, covering 4MB which coincided with -the fact that Torvald's first computer had 4MB of physical memory. Entries in -this single table were referred to as *PTE*:s - page table entries. +the fact that Torvalds's first computer had 4MB of physical memory. Entries in +this single table were referred to as *PTEs* - page table entries. The software page table hierarchy reflects the fact that page table hardware has become hierarchical and that in turn is done to save page table memory and @@ -212,7 +212,7 @@ threshold. Additionally, page faults may be also caused by code bugs or by maliciously crafted addresses that the CPU is instructed to access. A thread of a process could use instructions to address (non-shared) memory which does not belong to -its own address space, or could try to execute an instruction that want to write +its own address space, or could try to execute an instruction that wants to write to a read-only location. If the above-mentioned conditions happen in user-space, the kernel sends a @@ -277,5 +277,5 @@ To conclude this high altitude view of how Linux handles page faults, let's add that the page faults handler can be disabled and enabled respectively with `pagefault_disable()` and `pagefault_enable()`. -Several code path make use of the latter two functions because they need to +Several code paths make use of the latter two functions because they need to disable traps into the page faults handler, mostly to prevent deadlocks. diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst index 2e4da3d..bfe877a 100644 --- a/Documentation/process/maintainer-pgp-guide.rst +++ b/Documentation/process/maintainer-pgp-guide.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + .. _pgpguide: =========================== @@ -864,7 +866,7 @@ don't already have them):: If you have a kernel.org account, then you should `add the kernel.org UID to your key`_ to make WKD more useful to other kernel developers. -.. _`add the kernel.org UID to your key`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key +.. _`add the kernel.org UID to your key`: https://korg.docs.kernel.org/mail.html#adding-a-kernel-org-uid-to-your-pgp-key Web of Trust (WOT) vs. Trust on First Use (TOFU) ------------------------------------------------ diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst index f39d1d3..c18e307 100644 --- a/Documentation/process/programming-language.rst +++ b/Documentation/process/programming-language.rst @@ -3,10 +3,10 @@ Programming Language ==================== -The kernel is written in the C programming language [c-language]_. -More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ +The Linux kernel is written in the C programming language [c-language]_. +More precisely, it is typically compiled with ``gcc`` [gcc]_ under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11. -``clang`` [clang]_ is also supported, see docs on +``clang`` [clang]_ is also supported; see documentation on :ref:`Building Linux with Clang/LLVM `. This dialect contains many extensions to the language [gnu-extensions]_, diff --git a/tools/lib/python/kdoc/kdoc_parser.py b/tools/lib/python/kdoc/kdoc_parser.py index fd57944..ca00695 100644 --- a/tools/lib/python/kdoc/kdoc_parser.py +++ b/tools/lib/python/kdoc/kdoc_parser.py @@ -175,6 +175,7 @@ function_xforms = [ (KernRe(r"^__FORTIFY_INLINE +"), ""), (KernRe(r"__init +"), ""), (KernRe(r"__init_or_module +"), ""), + (KernRe(r"__exit +"), ""), (KernRe(r"__deprecated +"), ""), (KernRe(r"__flatten +"), ""), (KernRe(r"__meminit +"), ""),