Re: Question about Address Range Validation in Crash Kernel Allocation

From: Baoquan He <bhe@redhat.com>
To: "chenhaixiang (A)" <chenhaixiang3@huawei.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	chenhuacai@kernel.org, x86@kernel.org,
	Louhongxiang <louhongxiang@huawei.com>,
	"wangbin (A)" <wangbin224@huawei.com>,
	"Fangchuangchuang(Fcc,Euler)" <fangchuangchuang@huawei.com>,
	lihuafei <lihuafei1@huawei.com>,
	"wanghai (M)" <wanghai38@huawei.com>
Subject: Re: Question about Address Range Validation in Crash Kernel Allocation
Date: Thu, 21 Mar 2024 15:09:11 +0800	[thread overview]
Message-ID: <ZfvdFxR40Duh037w@MiWiFi-R3L-srv> (raw)
In-Reply-To: <45065451d7d343679e150313c1ee2b62@huawei.com>

On 03/21/24 at 03:22am, chenhaixiang (A) wrote:
> I'm sorry for the delay. Here are some details from the boot log and /proc/iomem:
> The Boot log:
> [    0.000000] Linux version 6.8.0 (root@localhost.localdomain) (gcc (GCC) 10.3.1, GNU ld (GNU Binutils) 2.37) #3 SMP PREEMPT_DYNAMIC Wed Mar 20 11:46:11 UTC 2024
> [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.8.0 root=/dev/mapper/root ro crashkernel=512M resume=/dev/mapper/swap rd.lvm.lv=root rd.lvm.lv=swap crash_kexec_post_notifiers softlockup_panic=1 reserve_kbox_mem=16M fsck.mode=auto fsck.repair=yes panic=3 nmi_watchdog=1 quiet rd.shell=0 memblock=debug efi=debug console=ttyS0,115200n8 console=tty0
......snip...
> [    0.022622] memblock_phys_alloc_range: 536870912 bytes align=0x1000000 from=0x0000000000000000 max_addr=0x0000000100000000 reserve_crashkernel_generic+0x7c/0x220
> [    0.022628] memblock_phys_alloc_range: 536870912 bytes align=0x1000000 from=0x0000000100000000 max_addr=0x0000400000000000 reserve_crashkernel_generic+0x7c/0x220
> [    0.022632] memblock_reserve: [0x000000c01f000000-0x000000c03effffff] memblock_alloc_range_nid+0xee/0x170
> [    0.022634] memblock_phys_alloc_range: 268435456 bytes align=0x1000000 from=0x0000000000000000 max_addr=0x0000000100000000 reserve_crashkernel_generic+0x11d/0x220
> [    0.022638] memblock_reserve: [0x0000000049000000-0x0000000058ffffff] memblock_alloc_range_nid+0xee/0x170
> [    0.022640] crashkernel low memory reserved: 0x49000000 - 0x59000000 (256 MB)
> [    0.022641] crashkernel reserved: 0x000000c01f000000 - 0x000000c03f000000 (512 MB)

Here, crashkernel,low is reserved in region:  [0x49000000 - 0x59000000] (256 MB)
      crashkernel,high is reserved in region: [0x000000c01f000000 - 0x000000c03f000000] (512 MB)
......
> [    0.029839] memblock_reserve: [0x000000c03ffff740-0x000000c03fffff7f] memblock_alloc_range_nid+0xee/0x170
> [    0.029843] e820: update [mem 0x53cbd000-0x53ccffff] usable ==> reserved
> [    0.029861] TSC deadline timer available

Then here, region [0x53cbd000-0x53ccffff] is reserved in e820, and print
abvoe "usable ==> reserved". This should be the step which prevents earlier
reserved crashkernel,low from being added to iomem tree. I am not sure
what triggered the e820 update.

How do you boot into your new 6.8.0 kernel? Used kexec -l to jump into
the 2nd kernel, or reboot from bios/firmware boot up into 6.8.0?

Reverting below commit should fix your problem, can you try it? 

commit 4a693ce65b186fddc1a73621bd6f941e6e3eca21
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Fri Dec 29 16:02:13 2023 +0800

    kdump: defer the insertion of crashkernel resources

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec