linux-kernel - Re: [tip: x86/cleanups] x86: Fix typos in comments

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191118121027.GA74767@gmail.com>
Date:   Mon, 18 Nov 2019 13:10:27 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     linux-kernel@...r.kernel.org
Cc:     linux-tip-commits@...r.kernel.org,
        Cao jin <caoj.fnst@...fujitsu.com>,
        Borislav Petkov <bp@...e.de>, "H. Peter Anvin" <hpa@...or.com>,
        Baoquan He <bhe@...hat.com>, Dave Young <dyoung@...hat.com>,
        David Howells <dhowells@...hat.com>,
        Ingo Molnar <mingo@...hat.com>,
        Juergen Gross <jgross@...e.com>,
        Robert Richter <rrichter@...vell.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Thomas Lendacky <Thomas.Lendacky@....com>,
        x86-ml <x86@...nel.org>, Borislav Petkov <bp@...en8.de>
Subject: Re: [tip: x86/cleanups] x86: Fix typos in comments


* tip-bot2 for Cao jin <tip-bot2@...utronix.de> wrote:

> The following commit has been merged into the x86/cleanups branch of tip:
> 
> Commit-ID:     11a98f37a5c11fd3cec9c7a566dfa902bceb5bde
> Gitweb:        https://git.kernel.org/tip/11a98f37a5c11fd3cec9c7a566dfa902bceb5bde
> Author:        Cao jin <caoj.fnst@...fujitsu.com>
> AuthorDate:    Mon, 18 Nov 2019 15:00:12 +08:00
> Committer:     Borislav Petkov <bp@...e.de>
> CommitterDate: Mon, 18 Nov 2019 10:03:26 +01:00
> 
> x86: Fix typos in comments
> 
> BIOSen -> BIOSes; paing -> paging. Append to 640 its proper unit "Kb".
> encomapssing -> encompassing.
> 
>  [ bp: Merge into a single patch, fix one more typo, massage. ]
> 
> Signed-off-by: Cao jin <caoj.fnst@...fujitsu.com>
> Signed-off-by: Borislav Petkov <bp@...e.de>
> Cc: "H. Peter Anvin" <hpa@...or.com>
> Cc: Baoquan He <bhe@...hat.com>
> Cc: Dave Young <dyoung@...hat.com>
> Cc: David Howells <dhowells@...hat.com>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Juergen Gross <jgross@...e.com>
> Cc: Robert Richter <rrichter@...vell.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Thomas Lendacky <Thomas.Lendacky@....com>
> Cc: x86-ml <x86@...nel.org>
> Link: https://lkml.kernel.org/r/20191118070012.27850-1-caoj.fnst@cn.fujitsu.com
> ---
>  arch/x86/kernel/setup.c | 6 +++---
>  arch/x86/mm/numa.c      | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 77ea96b..35b3f3a 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -459,7 +459,7 @@ static void __init memblock_x86_reserve_range_setup_data(void)
>   * due to mapping restrictions.
>   *
>   * On 64bit, kdump kernel need be restricted to be under 64TB, which is
> - * the upper limit of system RAM in 4-level paing mode. Since the kdump
> + * the upper limit of system RAM in 4-level paging mode. Since the kdump
>   * jumping could be from 5-level to 4-level, the jumping will fail if
>   * kernel is put above 64TB, and there's no way to detect the paging mode
>   * of the kernel which will be loaded for dumping during the 1st kernel

Beyond the typo, this whole paragraph is hard to read and inconsistent 
throughout.

How about something like this, on top? [ Feel free to backmerge, but can 
do a separate commit too - in which case I'll probably read the rest of 
the file too ;-) ]

Thanks,

	Ingo

 arch/x86/kernel/setup.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d398afd206b8..e9fa944d4ed8 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -468,15 +468,15 @@ static void __init memblock_x86_reserve_range_setup_data(void)
 /*
  * Keep the crash kernel below this limit.
  *
- * On 32 bits earlier kernels would limit the kernel to the low 512 MiB
+ * Earlier 32-bits kernels would limit the kernel to the low 512 MB range
  * due to mapping restrictions.
  *
- * On 64bit, kdump kernel need be restricted to be under 64TB, which is
+ * 64-bit kdump kernels need to be restricted to be under 64 TB, which is
  * the upper limit of system RAM in 4-level paging mode. Since the kdump
- * jumping could be from 5-level to 4-level, the jumping will fail if
- * kernel is put above 64TB, and there's no way to detect the paging mode
- * of the kernel which will be loaded for dumping during the 1st kernel
- * bootup.
+ * jump could be from 5-level paging to 4-level paging, the jump will fail if
+ * the kernel is put above 64 TB, and during the 1st kernel bootup there's
+ * no good way to detect the paging mode of the target kernel which will be
+ * loaded for dumping.
  */
 #ifdef CONFIG_X86_32
 # define CRASH_ADDR_LOW_MAX	SZ_512M