Changes in crash_reserve.c

7b54a96f - crash: remove an unused argument from reserve_crashkernel_generic()

Fri, 31 Jan 2025 11:38:25 +0000

crash: remove an unused argument from reserve_crashkernel_generic()cmdline argument is not used in reserve_crashkernel_generic() so removeit. Correspondingly, all the callers have been updated as well.No functional change intended.Link: https://lkml.kernel.org/r/20250131113830.925179-3-sourabhjain@linux.ibm.comSigned-off-by: Sourabh Jain Acked-by: Hari Bathini Acked-by: Baoquan He Cc: Madhavan Srinivasan Cc: Mahesh Salgaonkar Cc: Michael Ellerman Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/crash_reserve.c

b3f835cd - crash: Fix riscv64 crash memory reserve dead loop

Mon, 12 Aug 2024 06:20:17 +0000

crash: Fix riscv64 crash memory reserve dead loopOn RISCV64 Qemu machine with 512MB memory, cmdline "crashkernel=500M,high"will cause system stall as below: Zone ranges: DMA32 [mem 0x0000000080000000-0x000000009fffffff] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000080000000-0x000000008005ffff] node 0: [mem 0x0000000080060000-0x000000009fffffff] Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff] (stall here)commit 5d99cadf1568 ("crash: fix x86_32 crash memory reserve dead loopbug") fix this on 32-bit architecture. However, the problem is notcompletely solved. If `CRASH_ADDR_LOW_MAX = CRASH_ADDR_HIGH_MAX` on 64-bitarchitecture, for example, when system memory is equal toCRASH_ADDR_LOW_MAX on RISCV64, the following infinite loop will also occur: -> reserve_crashkernel_generic() and high is true -> alloc at [CRASH_ADDR_LOW_MAX, CRASH_ADDR_HIGH_MAX] fail -> alloc at [0, CRASH_ADDR_LOW_MAX] fail and repeatedly (because CRASH_ADDR_LOW_MAX = CRASH_ADDR_HIGH_MAX).As Catalin suggested, do not remove the ",high" reservation fallback to",low" logic which will change arm64's kdump behavior, but fix it byskipping the above situation similar to commit d2f32f23190b ("crash: fixx86_32 crash memory reserve dead loop").After this patch, it print: cannot allocate crashkernel (size:0x1f400000)Signed-off-by: Jinjie Ruan Suggested-by: Catalin Marinas Reviewed-by: Catalin Marinas Acked-by: Baoquan He Link: https://lore.kernel.org/r/20240812062017.2674441-1-ruanjinjie@huawei.comSigned-off-by: Palmer Dabbelt List of files: /linux-6.15/kernel/crash_reserve.c

59d58189 - crash: fix crash memory reserve exceed system memory bug

Mon, 29 Jul 2024 11:52:52 +0000

crash: fix crash memory reserve exceed system memory bugOn x86_32 Qemu machine with 1GB memory, the cmdline "crashkernel=4G" is okas 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 longlong" 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 andreturn 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.comSigned-off-by: Jinjie Ruan Suggested-by: Mike Rapoport Acked-by: Baoquan He Cc: Albert Ou Cc: Dave Young Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Vivek Goyal Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/crash_reserve.c

edb907a6 - crash: fix riscv64 crash memory reserve dead loop

Mon, 12 Aug 2024 06:20:17 +0000

crash: fix riscv64 crash memory reserve dead loopOn RISCV64 Qemu machine with 512MB memory, cmdline "crashkernel=500M,high"will cause system stall as below: Zone ranges: DMA32 [mem 0x0000000080000000-0x000000009fffffff] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000080000000-0x000000008005ffff] node 0: [mem 0x0000000080060000-0x000000009fffffff] Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff] (stall here)commit 5d99cadf1568 ("crash: fix x86_32 crash memory reserve dead loopbug") fix this on 32-bit architecture. However, the problem is notcompletely solved. If `CRASH_ADDR_LOW_MAX = CRASH_ADDR_HIGH_MAX` on64-bit architecture, for example, when system memory is equal toCRASH_ADDR_LOW_MAX on RISCV64, the following infinite loop will alsooccur: -> reserve_crashkernel_generic() and high is true -> alloc at [CRASH_ADDR_LOW_MAX, CRASH_ADDR_HIGH_MAX] fail -> alloc at [0, CRASH_ADDR_LOW_MAX] fail and repeatedly (because CRASH_ADDR_LOW_MAX = CRASH_ADDR_HIGH_MAX).As Catalin suggested, do not remove the ",high" reservation fallback to",low" logic which will change arm64's kdump behavior, but fix it byskipping the above situation similar to commit d2f32f23190b ("crash: fixx86_32 crash memory reserve dead loop").After this patch, it print: cannot allocate crashkernel (size:0x1f400000)Link: https://lkml.kernel.org/r/20240812062017.2674441-1-ruanjinjie@huawei.comSigned-off-by: Jinjie Ruan Suggested-by: Catalin Marinas Reviewed-by: Catalin Marinas Acked-by: Baoquan He Cc: Albert Ou Cc: Dave Young Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Vivek Goyal Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/crash_reserve.c

5eb1911a - crash: remove header files which are included more than once

Thu, 06 Jun 2024 09:14:27 +0000

crash: remove header files which are included more than onceFollowing warning is reported, so remove these duplicated headerincluding:./kernel/crash_reserve.c: linux/kexec.h is included more than once.This is just a clean code, no logic changed.Link: https://lkml.kernel.org/r/20240606091427.3512314-1-haowenchao22@gmail.comSigned-off-by: Wenchao Hao Acked-by: Baoquan He Cc: Dave Young Cc: Vivek Goyal Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/crash_reserve.c

4707c13d - crash: add prefix for crash dumping messages

Thu, 18 Apr 2024 03:58:43 +0000

crash: add prefix for crash dumping messagesAdd pr_fmt() to kernel/crash_core.c to add the module name to debuggingmessage printed as prefix.And also add prefix 'crashkernel:' to two lines of message printing codein kernel/crash_reserve.c. In kernel/crash_reserve.c, almost alldebugging messages have 'crashkernel:' prefix or there's keywordcrashkernel at the beginning or in the middle, adding pr_fmt() makes itredundant.Link: https://lkml.kernel.org/r/20240418035843.1562887-1-bhe@redhat.comSigned-off-by: Baoquan He Cc: Dave Young Cc: Jiri Slaby Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/crash_reserve.c

32fbe524 - crash: use macro to add crashk_res into iomem early for specific arch

Mon, 25 Mar 2024 01:50:50 +0000

crash: use macro to add crashk_res into iomem early for specific archThere are regression reports[1][2] that crashkernel region on x86_64 can'tbe added into iomem tree sometime. This causes the later failure of kdumploading.This happened after commit 4a693ce65b18 ("kdump: defer the insertion ofcrashkernel resources") was merged.Even though, these reported issues are proved to be related to othercomponent, they are just exposed after above commmit applied, I stillwould like to keep crashk_res and crashk_low_res being added into iomemearly as before because the early adding has been always there on x86_64and working very well. For safety of kdump, Let's change it back.Here, add a macro HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY to limit thatonly ARCH defining the macro can have the early addingcrashk_res/_low_res into iomem. Then defineHAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY on x86 to enable it.Note: In reserve_crashkernel_low(), there's a remnant of crashk_low_reshandling which was mistakenly added back in commit 85fcde402db1 ("kexec:split crashkernel reservation code out from crash_core.c").[1][PATCH V2] x86/kexec: do not update E820 kexec table for setup_datahttps://lore.kernel.org/all/Zfv8iCL6CT2JqLIC@darkstar.users.ipa.redhat.com/T/#u[2]Question about Address Range Validation in Crash Kernel Allocationhttps://lore.kernel.org/all/4eeac1f733584855965a2ea62fa4da58@huawei.com/T/#uLink: https://lkml.kernel.org/r/ZgDYemRQ2jxjLkq+@MiWiFi-R3L-srvFixes: 4a693ce65b18 ("kdump: defer the insertion of crashkernel resources")Signed-off-by: Baoquan He Cc: Dave Young Cc: Huacai Chen Cc: Ingo Molnar Cc: Jiri Bohac Cc: Li Huafei Cc: Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/crash_reserve.c

85fcde40 - kexec: split crashkernel reservation code out from crash_core.c

Wed, 24 Jan 2024 05:12:41 +0000

kexec: split crashkernel reservation code out from crash_core.cPatch series "Split crash out from kexec and clean up related configitems", v3.Motivation:=============Previously, LKP reported a building error. When investigating, it can'tbe resolved reasonablly with the present messy kdump config items. https://lore.kernel.org/oe-kbuild-all/202312182200.Ka7MzifQ-lkp@intel.com/The kdump (crash dumping) related config items could causes confusions:Firstly,CRASH_CORE enables codes including - crashkernel reservation; - elfcorehdr updating; - vmcoreinfo exporting; - crash hotplug handling;Now fadump of powerpc, kcore dynamic debugging and kdump all selectsCRASH_CORE, while fadump - fadump needs crashkernel parsing, vmcoreinfo exporting, and accessing global variable 'elfcorehdr_addr'; - kcore only needs vmcoreinfo exporting; - kdump needs all of the current kernel/crash_core.c.So only enabling PROC_CORE or FA_DUMP will enable CRASH_CORE, thismislead people that we enable crash dumping, actual it's not.Secondly,It's not reasonable to allow KEXEC_CORE select CRASH_CORE.Because KEXEC_CORE enables codes which allocate control pages, copykexec/kdump segments, and prepare for switching. These codes areshared by both kexec reboot and kdump. We could want kexec reboot,but disable kdump. In that case, CRASH_CORE should not be selected. -------------------- CONFIG_CRASH_CORE=y CONFIG_KEXEC_CORE=y CONFIG_KEXEC=y CONFIG_KEXEC_FILE=y ---------------------Thirdly,It's not reasonable to allow CRASH_DUMP select KEXEC_CORE.That could make KEXEC_CORE, CRASH_DUMP are enabled independently fromKEXEC or KEXEC_FILE. However, w/o KEXEC or KEXEC_FILE, the KEXEC_COREcode built in doesn't make any sense because no kernel loading orswitching will happen to utilize the KEXEC_CORE code. --------------------- CONFIG_CRASH_CORE=y CONFIG_KEXEC_CORE=y CONFIG_CRASH_DUMP=y ---------------------In this case, what is worse, on arch sh and arm, KEXEC relies on MMU,while CRASH_DUMP can still be enabled when !MMU, then compiling error isseen as the lkp test robot reported in above link. ------arch/sh/Kconfig------ config ARCH_SUPPORTS_KEXEC def_bool MMU config ARCH_SUPPORTS_CRASH_DUMP def_bool BROKEN_ON_SMP ---------------------------Changes:===========1, split out crash_reserve.c from crash_core.c;2, split out vmcore_infoc. from crash_core.c;3, move crash related codes in kexec_core.c into crash_core.c;4, remove dependency of FA_DUMP on CRASH_DUMP;5, clean up kdump related config items;6, wrap up crash codes in crash related ifdefs on all 8 arch-es which support crash dumping, except of ppc;Achievement:===========With above changes, I can rearrange the config item logic as below (the rightitem depends on or is selected by the left item): PROC_KCORE -----------> VMCORE_INFO |----------> VMCORE_INFO FA_DUMP----| |----------> CRASH_RESERVE ---->VMCORE_INFO / |---->CRASH_RESERVE KEXEC --| /| |--> KEXEC_CORE--> CRASH_DUMP-->/-|---->PROC_VMCORE KEXEC_FILE --| \ | \---->CRASH_HOTPLUG KEXEC --| |--> KEXEC_CORE (for kexec reboot only) KEXEC_FILE --|Test========On all 8 architectures, including x86_64, arm64, s390x, sh, arm, mips,riscv, loongarch, I did below three cases of config item setting andbuilding all passed. Take configs on x86_64 as exampmle here:(1) Both CONFIG_KEXEC and KEXEC_FILE is unset, then all kexec/kdumpitems are unset automatically:# Kexec and crash features# CONFIG_KEXEC is not set# CONFIG_KEXEC_FILE is not set# end of Kexec and crash features(2) set CONFIG_KEXEC_FILE and 'make olddefconfig':---------------# Kexec and crash featuresCONFIG_CRASH_RESERVE=yCONFIG_VMCORE_INFO=yCONFIG_KEXEC_CORE=yCONFIG_KEXEC_FILE=yCONFIG_CRASH_DUMP=yCONFIG_CRASH_HOTPLUG=yCONFIG_CRASH_MAX_MEMORY_RANGES=8192# end of Kexec and crash features---------------(3) unset CONFIG_CRASH_DUMP in case 2 and execute 'make olddefconfig':------------------------# Kexec and crash featuresCONFIG_KEXEC_CORE=yCONFIG_KEXEC_FILE=y# end of Kexec and crash features------------------------Note:For ppc, it needs investigation to make clear how to split out crashcode in arch folder. Hope Hari and Pingfan can help have a look, see ifit's doable. Now, I make it either have both kexec and crash enabled, ordisable both of them altogether.This patch (of 14):Both kdump and fa_dump of ppc rely on crashkernel reservation. Move therelevant codes into separate files: crash_reserve.c,include/linux/crash_reserve.h.And also add config item CRASH_RESERVE to control its enabling of thecodes. And update config items which has relationship with crashkernelreservation.And also change ifdeffery from CONFIG_CRASH_CORE to CONFIG_CRASH_RESERVEwhen those scopes are only crashkernel reservation related.And also rename arch/XXX/include/asm/{crash_core.h => crash_reserve.h} onarm64, x86 and risc-v because those architectures' crash_core.h is onlyrelated to crashkernel reservation.[akpm@linux-foundation.org: s/CRASH_RESEERVE/CRASH_RESERVE/, per Klara Modin]Link: https://lkml.kernel.org/r/20240124051254.67105-1-bhe@redhat.comLink: https://lkml.kernel.org/r/20240124051254.67105-2-bhe@redhat.comSigned-off-by: Baoquan He Acked-by: Hari Bathini Cc: Al Viro Cc: Eric W. Biederman Cc: Pingfan Liu Cc: Klara Modin Cc: Michael Kelley Cc: Nathan Chancellor Cc: Stephen Rothwell Cc: Yang Li Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/crash_reserve.c