32fbe52465
There are regression reports[1][2] that crashkernel region on x86_64 can't be added into iomem tree sometime. This causes the later failure of kdump loading. This happened after commit4a693ce65b("kdump: defer the insertion of crashkernel resources") was merged. Even though, these reported issues are proved to be related to other component, they are just exposed after above commmit applied, I still would like to keep crashk_res and crashk_low_res being added into iomem early as before because the early adding has been always there on x86_64 and 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 that only ARCH defining the macro can have the early adding crashk_res/_low_res into iomem. Then define HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY on x86 to enable it. Note: In reserve_crashkernel_low(), there's a remnant of crashk_low_res handling which was mistakenly added back in commit85fcde402d("kexec: split crashkernel reservation code out from crash_core.c"). [1] [PATCH V2] x86/kexec: do not update E820 kexec table for setup_data https://lore.kernel.org/all/Zfv8iCL6CT2JqLIC@darkstar.users.ipa.redhat.com/T/#u [2] Question about Address Range Validation in Crash Kernel Allocation https://lore.kernel.org/all/4eeac1f733584855965a2ea62fa4da58@huawei.com/T/#u Link: https://lkml.kernel.org/r/ZgDYemRQ2jxjLkq+@MiWiFi-R3L-srv Fixes:4a693ce65b("kdump: defer the insertion of crashkernel resources") Signed-off-by: Baoquan He <bhe@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Huacai Chen <chenhuacai@loongson.cn> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Bohac <jbohac@suse.cz> Cc: Li Huafei <lihuafei1@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
44 lines
1.3 KiB
C
44 lines
1.3 KiB
C
/* SPDX-License-Identifier: GPL-2.0 */
|
|
#ifndef _X86_CRASH_RESERVE_H
|
|
#define _X86_CRASH_RESERVE_H
|
|
|
|
/* 16M alignment for crash kernel regions */
|
|
#define CRASH_ALIGN SZ_16M
|
|
|
|
/*
|
|
* Keep the crash kernel below this limit.
|
|
*
|
|
* Earlier 32-bits kernels would limit the kernel to the low 512 MB range
|
|
* due to mapping restrictions.
|
|
*
|
|
* 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
|
|
* 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.
|
|
*/
|
|
extern unsigned long swiotlb_size_or_default(void);
|
|
|
|
#ifdef CONFIG_X86_32
|
|
# define CRASH_ADDR_LOW_MAX SZ_512M
|
|
# define CRASH_ADDR_HIGH_MAX SZ_512M
|
|
#else
|
|
# define CRASH_ADDR_LOW_MAX SZ_4G
|
|
# define CRASH_ADDR_HIGH_MAX SZ_64T
|
|
#endif
|
|
|
|
# define DEFAULT_CRASH_KERNEL_LOW_SIZE crash_low_size_default()
|
|
|
|
static inline unsigned long crash_low_size_default(void)
|
|
{
|
|
#ifdef CONFIG_X86_64
|
|
return max(swiotlb_size_or_default() + (8UL << 20), 256UL << 20);
|
|
#else
|
|
return 0;
|
|
#endif
|
|
}
|
|
|
|
#define HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY
|
|
|
|
#endif /* _X86_CRASH_RESERVE_H */
|