| Message ID | 20240719095735.1912878-3-ruanjinjie@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | crash: Fix x86_32 memory reserve dead loop bug | expand |
On 07/19/24 at 05:57pm, Jinjie Ruan wrote: > On x86_32 Qemu machine with 1GB memory, the cmdline "crashkernel=512M" will > also cause system stall as below: > > ACPI: Reserving FACP table memory at [mem 0x3ffe18b8-0x3ffe192b] > ACPI: Reserving DSDT table memory at [mem 0x3ffe0040-0x3ffe18b7] > ACPI: Reserving FACS table memory at [mem 0x3ffe0000-0x3ffe003f] > ACPI: Reserving APIC table memory at [mem 0x3ffe192c-0x3ffe19bb] > ACPI: Reserving HPET table memory at [mem 0x3ffe19bc-0x3ffe19f3] > ACPI: Reserving WAET table memory at [mem 0x3ffe19f4-0x3ffe1a1b] > 143MB HIGHMEM available. > 879MB LOWMEM available. > mapped low ram: 0 - 36ffe000 > low ram: 0 - 36ffe000 > (stall here) > > The reason is that the CRASH_ADDR_LOW_MAX is equal to CRASH_ADDR_HIGH_MAX > on x86_32, the first "low" crash kernel memory reservation for 512M fails, > then it go into the "retry" loop and never came out as below (consider > CRASH_ADDR_LOW_MAX = CRASH_ADDR_HIGH_MAX = 512M): > > -> reserve_crashkernel_generic() and high is false > -> alloc at [0, 0x20000000] fail > -> alloc at [0x20000000, 0x20000000] fail and repeatedly > (because CRASH_ADDR_LOW_MAX = CRASH_ADDR_HIGH_MAX). > > Fix it by skipping meaningless calls of memblock_phys_alloc_range() with > `start = end` > > After this patch, the retry dead loop is avoided and print below info: > cannot allocate crashkernel (size:0x20000000) > > And apply generic crashkernel reservation to 32bit system will be ready. ~~~ applying Other than this nit, it looks good to me. Acked-by: Baoquan He <bhe@redhat.com> > > Fixes: 9c08a2a139fe ("x86: kdump: use generic interface to simplify crashkernel reservation code") > Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> > Suggested-by: Baoquan He <bhe@redhat.com> > --- > v4: > - Signed-off-by -> Suggested-by as suggested. > - Remove the Tested-by as suggested. > - Update the commit subject > v3: > - Fix it as Baoquan suggested. > - Update the commit message. > --- > kernel/crash_reserve.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/crash_reserve.c b/kernel/crash_reserve.c > index c5213f123e19..dacc268429e2 100644 > --- a/kernel/crash_reserve.c > +++ b/kernel/crash_reserve.c > @@ -414,7 +414,8 @@ void __init reserve_crashkernel_generic(char *cmdline, > search_end = CRASH_ADDR_HIGH_MAX; > search_base = CRASH_ADDR_LOW_MAX; > crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE; > - goto retry; > + if (search_base != search_end) > + goto retry; > } > > /* > -- > 2.34.1 >
diff --git a/kernel/crash_reserve.c b/kernel/crash_reserve.c index c5213f123e19..dacc268429e2 100644 --- a/kernel/crash_reserve.c +++ b/kernel/crash_reserve.c @@ -414,7 +414,8 @@ void __init reserve_crashkernel_generic(char *cmdline, search_end = CRASH_ADDR_HIGH_MAX; search_base = CRASH_ADDR_LOW_MAX; crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE; - goto retry; + if (search_base != search_end) + goto retry; } /*
On x86_32 Qemu machine with 1GB memory, the cmdline "crashkernel=512M" will also cause system stall as below: ACPI: Reserving FACP table memory at [mem 0x3ffe18b8-0x3ffe192b] ACPI: Reserving DSDT table memory at [mem 0x3ffe0040-0x3ffe18b7] ACPI: Reserving FACS table memory at [mem 0x3ffe0000-0x3ffe003f] ACPI: Reserving APIC table memory at [mem 0x3ffe192c-0x3ffe19bb] ACPI: Reserving HPET table memory at [mem 0x3ffe19bc-0x3ffe19f3] ACPI: Reserving WAET table memory at [mem 0x3ffe19f4-0x3ffe1a1b] 143MB HIGHMEM available. 879MB LOWMEM available. mapped low ram: 0 - 36ffe000 low ram: 0 - 36ffe000 (stall here) The reason is that the CRASH_ADDR_LOW_MAX is equal to CRASH_ADDR_HIGH_MAX on x86_32, the first "low" crash kernel memory reservation for 512M fails, then it go into the "retry" loop and never came out as below (consider CRASH_ADDR_LOW_MAX = CRASH_ADDR_HIGH_MAX = 512M): -> reserve_crashkernel_generic() and high is false -> alloc at [0, 0x20000000] fail -> alloc at [0x20000000, 0x20000000] fail and repeatedly (because CRASH_ADDR_LOW_MAX = CRASH_ADDR_HIGH_MAX). Fix it by skipping meaningless calls of memblock_phys_alloc_range() with `start = end` After this patch, the retry dead loop is avoided and print below info: cannot allocate crashkernel (size:0x20000000) And apply generic crashkernel reservation to 32bit system will be ready. Fixes: 9c08a2a139fe ("x86: kdump: use generic interface to simplify crashkernel reservation code") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Suggested-by: Baoquan He <bhe@redhat.com> --- v4: - Signed-off-by -> Suggested-by as suggested. - Remove the Tested-by as suggested. - Update the commit subject v3: - Fix it as Baoquan suggested. - Update the commit message. --- kernel/crash_reserve.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)