linux-kernel - [PATCH] Minor documentation fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20250722191139.7195-1-bojanalahithashri@gmail.com>
Date: Tue, 22 Jul 2025 15:11:35 -0400
From: Bojanala Hithashri <bojanalahithashri@...il.com>
To: 
Cc: linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org,
	Bojanala Hithashri <bojanalahithashri@...il.com>
Subject: [PATCH] Minor documentation fixes

Signed-off-by: Bojanala Hithashri <bojanalahithashri@...il.com>
---
 Documentation/block/data-integrity.rst                | 2 +-
 Documentation/bpf/standardization/instruction-set.rst | 2 +-
 Documentation/cdrom/cdrom-standard.rst                | 2 +-
 Documentation/trace/boottime-trace.rst                | 2 +-
 Documentation/trace/events.rst                        | 2 +-
 Documentation/trace/fprobe.rst                        | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/block/data-integrity.rst b/Documentation/block/data-integrity.rst
index 99905e880a0e..b7b10c8abbcc 100644
--- a/Documentation/block/data-integrity.rst
+++ b/Documentation/block/data-integrity.rst
@@ -154,7 +154,7 @@ bio_free() will automatically free the bip.
 ----------------
 
 Block devices can set up the integrity information in the integrity
-sub-struture of the queue_limits structure.
+sub-structure of the queue_limits structure.
 
 Layered block devices will need to pick a profile that's appropriate
 for all subdevices.  queue_limits_stack_integrity() can help with that.  DM
diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
index fbe975585236..746eb3c421eb 100644
--- a/Documentation/bpf/standardization/instruction-set.rst
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -350,7 +350,7 @@ Underflow and overflow are allowed during arithmetic operations, meaning
 the 64-bit or 32-bit value will wrap. If BPF program execution would
 result in division by zero, the destination register is instead set to zero.
 Otherwise, for ``ALU64``, if execution would result in ``LLONG_MIN``
-dividing -1, the desination register is instead set to ``LLONG_MIN``. For
+dividing -1, the destination register is instead set to ``LLONG_MIN``. For
 ``ALU``, if execution would result in ``INT_MIN`` dividing -1, the
 desination register is instead set to ``INT_MIN``.
 
diff --git a/Documentation/cdrom/cdrom-standard.rst b/Documentation/cdrom/cdrom-standard.rst
index 6c1303cff159..22dc6db04a14 100644
--- a/Documentation/cdrom/cdrom-standard.rst
+++ b/Documentation/cdrom/cdrom-standard.rst
@@ -89,7 +89,7 @@ CD-ROM devices behave **exactly** the same (insofar as the underlying
 hardware will allow).
 
 The goal of the Uniform CD-ROM Driver is **not** to alienate driver developers
-whohave not yet taken steps to support this effort. The goal of Uniform CD-ROM
+who have not yet taken steps to support this effort. The goal of Uniform CD-ROM
 Driver is simply to give people writing application programs for CD-ROM drives
 **one** Linux CD-ROM interface with consistent behavior for all
 CD-ROM devices. In addition, this also provides a consistent interface
diff --git a/Documentation/trace/boottime-trace.rst b/Documentation/trace/boottime-trace.rst
index d594597201fd..62646130e1a2 100644
--- a/Documentation/trace/boottime-trace.rst
+++ b/Documentation/trace/boottime-trace.rst
@@ -198,7 +198,7 @@ Most of the subsystems and architecture dependent drivers will be initialized
 after that (arch_initcall or subsys_initcall). Thus, you can trace those with
 boot-time tracing.
 If you want to trace events before core_initcall, you can use the options
-starting with ``kernel``. Some of them will be enabled eariler than the initcall
+starting with ``kernel``. Some of them will be enabled earlier than the initcall
 processing (for example,. ``kernel.ftrace=function`` and ``kernel.trace_event``
 will start before the initcall.)
 
diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
index 2d88a2acacc0..c35f640e1cdc 100644
--- a/Documentation/trace/events.rst
+++ b/Documentation/trace/events.rst
@@ -629,7 +629,7 @@ following:
   - tracing synthetic events from in-kernel code
   - the low-level "dynevent_cmd" API
 
-7.1 Dyamically creating synthetic event definitions
+7.1 Dynamically creating synthetic event definitions
 ---------------------------------------------------
 
 There are a couple ways to create a new synthetic event from a kernel
diff --git a/Documentation/trace/fprobe.rst b/Documentation/trace/fprobe.rst
index 71cd40472d36..d632073408d6 100644
--- a/Documentation/trace/fprobe.rst
+++ b/Documentation/trace/fprobe.rst
@@ -118,7 +118,7 @@ will be cancelled.
 @fregs
         This is the `ftrace_regs` data structure at the entry and exit. This
         includes the function parameters, or the return values. So user can
-        access thos values via appropriate `ftrace_regs_*` APIs.
+        access those values via appropriate `ftrace_regs_*` APIs.
 
 @entry_data
         This is a local storage to share the data between entry and exit handlers.
-- 
2.47.0