[PATCH] crashdump-x86.c:Add a check for the crash kernel range in exclude_region()
In some cases, such as start < mstart < mend < end when exclude_region(),
this results in crash_memory_range[i].end becoming less than
crash_memory_range[i].start, leading to incorrect address ranges.
Adding a range check should be necessary.
Signed-off-by: chenhaixiang chenhaixia...@huawei.com
---
kexec/arch/i386/crashdump-x86.c | 8
1 file changed, 8 insertions(+)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index a01031e..30e9a41 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -447,6 +447,14 @@ static int exclude_region(int *nr_ranges, uint64_t start,
uint64_t end)
else
crash_memory_range[i].start = end + 1;
}
+ if (crash_memory_range[i].end < crash_memory_range[i].start) {
+ /* Crash memory range is unreasonable. */
+ fprintf(stderr, "Error: Crash memory range is
unreasonable.\n");
+ dbgprintf("exclude_region: crash_memory_range[%d]\n"
+ "start = %016llx,end = %016llx\n",
+ i, crash_memory_range[i].start,
crash_memory_range[i].end);
+return -1;
+ }
}
/* Insert split memory region, if any. */
if (tidx >= 0) {
--
2.33.0
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: Question about Address Range Validation in Crash Kernel Allocation
> > I'm sorry for the delay. Here are some details from the boot log and > /proc/iomem: > > The Boot log: > > [0.00] 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.00] 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=0x100 > from=0x max_addr=0x0001 > reserve_crashkernel_generic+0x7c/0x220 > > [0.022628] memblock_phys_alloc_range: 536870912 bytes align=0x100 > from=0x0001 max_addr=0x4000 > reserve_crashkernel_generic+0x7c/0x220 > > [0.022632] memblock_reserve: [0x00c01f00-0x00c03eff] > memblock_alloc_range_nid+0xee/0x170 > > [0.022634] memblock_phys_alloc_range: 268435456 bytes align=0x100 > from=0x max_addr=0x0001 > reserve_crashkernel_generic+0x11d/0x220 > > [0.022638] memblock_reserve: [0x4900-0x58ff] > memblock_alloc_range_nid+0xee/0x170 > > [0.022640] crashkernel low memory reserved: 0x4900 - 0x5900 > (256 MB) > > [0.022641] crashkernel reserved: 0x00c01f00 - > 0x00c03f00 (512 MB) > > Here, crashkernel,low is reserved in region: [0x4900 - 0x5900] (256 > MB) > crashkernel,high is reserved in region: [0x00c01f00 - > 0x00c03f00] (512 MB) .. > > [0.029839] memblock_reserve: [0x00c03740-0x00c03f7f] > memblock_alloc_range_nid+0xee/0x170 > > [0.029843] e820: update [mem 0x53cbd000-0x53cc] usable ==> > reserved > > [0.029861] TSC deadline timer available > > Then here, region [0x53cbd000-0x53cc] 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. Current analysis suggests that efi_reserve_boot_services() is causing the update of the e820 table. > > 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? It's reboot from bios boot up into 6.8.0. I attempted to revert the below patch, and this time the conflicting segment "53cbd000-53cc" also appeared in the /proc/iomem of the 6.8 kernel. 2d4fd058-60efefff : System RAM 2d4fd058-58ff : System RAM 4900-58ff : Crash kernel 53cbd000-53cc : Reserved 60eff000-704fefff : Reserved -- 93dd424000-93dd9f : Kernel bss c01f00-c03eff : Crash kernel d00-d0f : PCI Bus :00 d00-d1f : PCI Bus :01 > > Reverting below commit should fix your problem, can you try it? > > commit 4a693ce65b186fddc1a73621bd6f941e6e3eca21 > Author: Huacai Chen > 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
Re: Question about Address Range Validation in Crash Kernel Allocation
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: 0x4900 - 0x5900 (256 MB)
[0.022641] crashkernel reserved: 0x00c01f00 - 0x00c03f00
(512 MB)
But only one segment is shown in /proc/iomem:
c01f00-c03eff : Crash kernel
Moreover, the conflicting address 53cbd000-53cc is still reserved by
someone else:
53cbd000-53cc : Reserved
[0.029843] e820: update [mem 0x53cbd000-0x53cc] 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-58ff : System RAM
> > 4900-58ff : Crash kernel
> > 53cbd000-53cc : 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-58ff : System RAM
> > > > 4900-58ff : Crash kernel
> > > > 53cbd000-53cc : 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-oozns...@darkstar.users.ipa.redh
> > > at.com/
> > > T/#u
> > >
> > > Thanks
> > > Baoquan
> > >
> > > >
> > > > The crash_memory_range array will encounter incorrect address ranges:
> > > > CRASH MEMORY RANGES
> > > > 2d4fd058-48ff (0)
> > > > 53cbd000-48ff (1)
> > > > 5900-53cc (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)
> > > >
Re: Question about Address Range Validation in Crash Kernel Allocation
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.
```
cat /proc/iomem
2d4fd058-58ff : System RAM
4900-58ff : Crash kernel
53cbd000-53cc : 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-58ff : System RAM
> > 4900-58ff : Crash kernel
> > 53cbd000-53cc : 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-oozns...@darkstar.users.ipa.redhat.com/
> T/#u
>
> Thanks
> Baoquan
>
> >
> > The crash_memory_range array will encounter incorrect address ranges:
> > CRASH MEMORY RANGES
> > 2d4fd058-48ff (0)
> > 53cbd000-48ff (1)
> > 5900-53cc (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
Question about Address Range Validation in Crash Kernel Allocation
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-58ff : System RAM
4900-58ff : Crash kernel
53cbd000-53cc : Reserved
The crash_memory_range array will encounter incorrect address ranges:
CRASH MEMORY RANGES
2d4fd058-48ff (0)
53cbd000-48ff (1)
5900-53cc (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
