| Message ID | 20240722035701.696874-2-ruanjinjie@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | crash: Fix crash memory reserve exceed system memory bug | expand |
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 5d34cad9b7b1..77b937dbd98c 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -482,6 +482,11 @@ static void __init arch_reserve_crashkernel(void) if (ret) return; + if (crash_size >= memblock_phys_mem_size()) { + pr_warn("Crashkernel: invalid size."); + return; + } + if (xen_pv_domain()) { pr_info("Ignoring crashkernel for a Xen PV domain\n"); return;
On x86_32 Qemu machine with 1GB memory, the cmdline "crashkernel=4G" is ok as below: crashkernel reserved: 0x0000000020000000 - 0x0000000120000000 (4096 MB) The cause is that the crash_size is parsed and printed with "unsigned long long" data type which is 8 bytes but allocated used with "phys_addr_t" which is 4 bytes in memblock_phys_alloc_range(). Fix it by checking if the crash_size is greater than system RAM size and warn out as parse_crashkernel_mem() do it if so as Baoquan suggested. After this patch, it fails and there is no above confusing reserve success info. Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Suggested-by: Baoquan He <bhe@redhat.com> --- v4: - Update the warn info to align with parse_crashkernel_mem(). - Update the commit message. v3: - Handle the check in arch_reserve_crashkernel() Baoquan suggested. - Split x86_32 and arm32. - Add Suggested-by. - Drop the wrong fix tag. v2: - Also fix for x86_32. - Update the fix method. - Peel off the other two patches. - Update the commit message. --- arch/x86/kernel/setup.c | 5 +++++ 1 file changed, 5 insertions(+)