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]

Date:   Mon, 18 Nov 2019 13:46:34 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org,
        Cao jin <caoj.fnst@...fujitsu.com>,
        "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>
Subject: Re: [tip: x86/cleanups] x86: Fix typos in comments

On Mon, Nov 18, 2019 at 01:10:27PM +0100, Ingo Molnar wrote:
> 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

Yap, sure.

Except that tglx committed another patch ontop of x86/cleanups in the
meantime. I leave it up to you to decide what to do. I'd backmerge and
rebase but this is just me.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette