summaryrefslogtreecommitdiff
path: root/kernel
diff options
context:
space:
mode:
authorJinjie Ruan <ruanjinjie@huawei.com>2024-07-29 19:52:52 +0800
committerAndrew Morton <akpm@linux-foundation.org>2024-09-01 20:43:30 -0700
commit59d58189f3d96eeb31b0b4a8a8aab2cd6a6afb82 (patch)
treece7b0ccb4e4cc18a7d03a4182adab358f51a4da6 /kernel
parent00bd8ec2f7cb40e438f5c9eb9ea2110d1ce5e165 (diff)
downloadlwn-59d58189f3d96eeb31b0b4a8a8aab2cd6a6afb82.tar.gz
lwn-59d58189f3d96eeb31b0b4a8a8aab2cd6a6afb82.zip
crash: fix crash memory reserve exceed system memory bug
On x86_32 Qemu machine with 1GB memory, the cmdline "crashkernel=4G" is ok as below: crashkernel reserved: 0x0000000020000000 - 0x0000000120000000 (4096 MB) It's similar on other architectures, such as ARM32 and RISCV32. 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 crash_size is greater than system RAM size and return error if so. After this patch, there is no above confusing reserve success info. Link: https://lkml.kernel.org/r/20240729115252.1659112-1-ruanjinjie@huawei.com Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Suggested-by: Mike Rapoport <rppt@kernel.org> Acked-by: Baoquan He <bhe@redhat.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Dave Young <dyoung@redhat.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'kernel')
-rw-r--r--kernel/crash_reserve.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/kernel/crash_reserve.c b/kernel/crash_reserve.c
index 64d44a52c011..a620fb4b2116 100644
--- a/kernel/crash_reserve.c
+++ b/kernel/crash_reserve.c
@@ -335,6 +335,9 @@ int __init parse_crashkernel(char *cmdline,
if (!*crash_size)
ret = -EINVAL;
+ if (*crash_size >= system_ram)
+ ret = -EINVAL;
+
return ret;
}