linux-kernel - Re: [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>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87c18bb9-b2a7-4326-b163-01641ffff065@linux.dev>
Date: Mon, 11 Aug 2025 15:55:53 +0800
From: Kunwu Chan <kunwu.chan@...ux.dev>
To: Bojanala Hithashri <bojanalahithashri@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH] Minor documentation fixes

On 2025/7/23 03:11, Bojanala Hithashri wrote:
> 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.

lgtm


Reviewed-by: Kunwu Chan <kunwu.chan@...ux.dev>

-- 
Thanks,
        Kunwu Chan.