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
|