Re: Question about Address Range Validation in Crash Kernel Allocation

From: "chenhaixiang (A)" <chenhaixiang3@huawei.com>
To: Baoquan He <bhe@redhat.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.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: Wed, 20 Mar 2024 13:12:22 +0000	[thread overview]
Message-ID: <b1c67ea9d8fe4f6f832d9272be177bec@huawei.com> (raw)

I tested the kernel-6.8 on my machine and found that the crashkernel memory reservation range is consistent with kernel-5.10. However, it's strange that when crashkernel=512M, the kernel still allocates two memory segments for crashkernel, as seen in the logs:
[    0.022640] crashkernel low memory reserved: 0x49000000 - 0x59000000 (256 MB)
[    0.022641] crashkernel reserved: 0x000000c01f000000 - 0x000000c03f000000 (512 MB)
But only one segment is shown in /proc/iomem:
	c01f000000-c03effffff : Crash kernel
Moreover, the conflicting address 53cbd000-53ccffff is still reserved by someone else:
	53cbd000-53ccffff : Reserved
[    0.029843] e820: update [mem 0x53cbd000-0x53ccffff] usable ==> reserved
It seems there is a kernel bug here.
If you need the complete log, I can send it later.
---------
On 03/19/24 at 4:22pm, Baoquan He wrote:
> On 03/19/24 at 07:24am, chenhaixiang (A) wrote:
> > Thank you for your reply!
> > The kernel version on my machine is kernel-5.10, and the kexec-tools version is
> kexec-tools-2.0.27.
> > However, my issue seems to be a bit different. On my machine, I can see the
> crashkernel memory segment in /proc/iomem. However, for some reason,
> within the address range allocated for crashkernel, there is also a segment
> marked as 'Reserved' (I'm not sure who marked it). In this scenario, kexec-tools
> calculates the CRASH MEMORY RANGES incorrectly.
> > ```
> 
> crashkernel region can't be reserved again once it's allocated and reserved in
> memblock. There must be something wrong with the code. You can try upstream
> kernel and kexec-tools to see if it exists too. Since you are using an old kernel and
> could be on a distros, we may not be able to cover it. Sorry about that.
> 
> If you want to debug to find out the reason, I can help give suggestions.
> 
> > cat /proc/iomem
> > 2d4fd058-58ffffff : System RAM
> >   49000000-58ffffff : Crash kernel
> >     53cbd000-53ccffff : Reserved
> > ```
> > I'm not sure if the crashkernel memory segment should not include other
> markings, and if not supported, whether kexec-tools should raise an error.
> > Thanks
> > Chen Haixiang
> > ----------
> > On 03/19/24 at 9:38qm, Baoquan He wrote:
> > > Hi,
> > >
> > > On 03/18/24 at 12:00pm, chenhaixiang (A) wrote:
> > > > Dear kexec Community Members,
> > > >
> > > > I encountered an issue while using kexec-tools on my x86_64 machine.
> > > > When there is a segment marked as 'reserved' within the memory
> > > > range
> > > allocated for the crash kernel in /proc/iomem,the output appears as follows:
> > > > 2d4fd058-60efefff : System RAM
> > > >   2d4fd058-58ffffff : System RAM
> > > >     49000000-58ffffff : Crash kernel
> > > >       53cbd000-53ccffff : Reserved
> > >
> > > What kernel are you using? the version of kernel, and kexec-tools?
> > >
> > > If you are testing on the latest mainline kernel, you could meet the
> > > issue Dave have met and fixed in below patch:
> > >
> > > [PATCH] x86/kexec: do not update E820 kexec table for setup_data
> > > https://lore.kernel.org/all/ZeZ2Kos-OOZNSrmO@darkstar.users.ipa.redh
> > > at.com/
> > > T/#u
> > >
> > > Thanks
> > > Baoquan
> > >
> > > >
> > > > The crash_memory_range array will encounter incorrect address ranges:
> > > > CRASH MEMORY RANGES
> > > > 000000002d4fd058-0000000048ffffff (0)
> > > > 0000000053cbd000-0000000048ffffff (1)
> > > > 0000000059000000-0000000053ccffff (0)
> > > >
> > > > Read the code, I noticed that the get_crash_memory_ranges()
> > > > function
> > > invokes exclude_region() to handle the splitting of memory regions,
> > > but it seems unable to properly handle the scenario described above.
> > > > The code logic is as follows:
> > > > ...
> > > > 	if (start < mend && end > mstart) {
> > > > 		if (start != mstart && end != mend) {
> > > > 			/* Split memory region */
> > > > 			crash_memory_range[i].end = start - 1;
> > > > 			temp_region.start = end + 1;
> > > > 			temp_region.end = mend;
> > > > 			temp_region.type = RANGE_RAM;
> > > > 			tidx = i+1;
> > > > 		} else if (start != mstart)
> > > > 			crash_memory_range[i].end = start - 1;
> > > > 		else
> > > > 			crash_memory_range[i].start = end + 1;
> > > > 	}
> > > > ...
> > > > If start < mstart < mend < end, resulting in
> > > > crash_memory_range[i].end
> > > becoming less than crash_memory_range[i].start, leading to incorrect
> > > address ranges.
> > > > I would like to know if this behavior is reasonable and whether it
> > > > is necessary to
> > > validate the address ranges for compliance at the end.
> > > >
> > > > Thank you for your time and assistance.
> > > >
> > > > Chen Haixiang
> > > >
> > > > _______________________________________________
> > > > kexec mailing list
> > > > kexec@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/kexec
> > > >
> >


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