Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: Question about Address Range Validation in Crash Kernel Allocation
@ 2024-03-21  9:17 chenhaixiang (A)
  2024-03-21  9:48 ` Li Huafei
  0 siblings, 1 reply; 15+ messages in thread
From: chenhaixiang (A) @ 2024-03-21  9:17 UTC (permalink / raw)
  To: Baoquan He
  Cc: kexec@lists.infradead.org, chenhuacai@kernel.org, x86@kernel.org,
	Louhongxiang, wangbin (A), Fangchuangchuang(Fcc,Euler), lihuafei,
	wanghai (M), Wangkefeng (OS Kernel Lab)


> > 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.
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-53ccffff" also appeared in the /proc/iomem
 of the 6.8 kernel.

2d4fd058-60efefff : System RAM
  2d4fd058-58ffffff : System RAM
    49000000-58ffffff : Crash kernel
      53cbd000-53ccffff : Reserved
60eff000-704fefff : Reserved
--
  93dd424000-93dd9fffff : Kernel bss
  c01f000000-c03effffff : Crash kernel
d0000000000-d0fffffffff : PCI Bus 0000:00
  d0000000000-d00001fffff : PCI Bus 0000:01
> 
> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Question about Address Range Validation in Crash Kernel Allocation
@ 2024-03-20 13:12 chenhaixiang (A)
  2024-03-20 14:08 ` Baoquan He
  0 siblings, 1 reply; 15+ messages in thread
From: chenhaixiang (A) @ 2024-03-20 13:12 UTC (permalink / raw)
  To: Baoquan He
  Cc: kexec@lists.infradead.org, Louhongxiang, wangbin (A),
	Fangchuangchuang(Fcc,Euler), lihuafei, wanghai (M)

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

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Question about Address Range Validation in Crash Kernel Allocation
@ 2024-03-19  7:24 chenhaixiang (A)
  2024-03-19  8:21 ` Baoquan He
  0 siblings, 1 reply; 15+ messages in thread
From: chenhaixiang (A) @ 2024-03-19  7:24 UTC (permalink / raw)
  To: Baoquan He
  Cc: kexec@lists.infradead.org, Louhongxiang, wangbin (A),
	Fangchuangchuang(Fcc,Euler), chenhaixiang (A)

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-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.redhat.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

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Question about Address Range Validation in Crash Kernel Allocation
@ 2024-03-18 12:00 chenhaixiang (A)
  2024-03-19  1:38 ` Baoquan He
  0 siblings, 1 reply; 15+ messages in thread
From: chenhaixiang (A) @ 2024-03-18 12:00 UTC (permalink / raw)
  To: kexec@lists.infradead.org
  Cc: Louhongxiang, wangbin (A), chenhaixiang (A),
	Fangchuangchuang(Fcc,Euler)

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

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

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-03-22  7:58 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <45065451d7d343679e150313c1ee2b62@huawei.com>
2024-03-21  7:09 ` Question about Address Range Validation in Crash Kernel Allocation Baoquan He
2024-03-21  9:17 chenhaixiang (A)
2024-03-21  9:48 ` Li Huafei
2024-03-21 10:06   ` Dave Young
2024-03-21 12:37     ` Li Huafei
2024-03-22  1:16       ` Baoquan He
2024-03-22  7:26         ` Dave Young
2024-03-22  7:18       ` Dave Young
2024-03-22  7:58         ` Li Huafei
  -- strict thread matches above, loose matches on Subject: below --
2024-03-20 13:12 chenhaixiang (A)
2024-03-20 14:08 ` Baoquan He
2024-03-19  7:24 chenhaixiang (A)
2024-03-19  8:21 ` Baoquan He
2024-03-18 12:00 chenhaixiang (A)
2024-03-19  1:38 ` Baoquan He

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox