Re: Question about Address Range Validation in Crash Kernel Allocation
On 2024/3/22 15:18, Dave Young wrote: > On Thu, 21 Mar 2024 at 20:37, Li Huafei wrote: >> >> >> >> On 2024/3/21 18:06, Dave Young wrote: >>> Hi, >>> >>> On Thu, 21 Mar 2024 at 17:49, Li Huafei wrote: Hi Baoquan， On 2024/3/21 17:17, chenhaixiang (A) wrote: > >>> 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. We added dump_stack () printing in efi_mem_reserve () and found that [0x53cbd000-0x53cc] was reserved by BGRT: [0.032259] e820: update [mem 0x53cbd000-0x53cc] usable ==> reserved [0.032262] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-60.18.0.50.h820.eulerosv2r11.x86_64 #7 [0.032263] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 8.25 08/30/2022 [0.032264] Call Trace: [0.032265] ? dump_stack+0x57/0x6e [0.032267] ? bgrt_init+0xc2/0xc2 [0.032268] ? __e820__range_update+0x7a/0x1d6 [0.032270] ? bgrt_init+0xc2/0xc2 [0.032272] ? bgrt_init+0xc2/0xc2 [0.032274] ? efi_arch_mem_reserve+0x1a3/0x1d0 [0.032276] ? efi_mem_reserve+0x2d/0x42 [0.032278] ? acpi_parse_bgrt+0xa/0x11 [0.032279] ? acpi_table_parse+0x86/0xbc [0.032281] ? acpi_boot_init+0x79/0xad [0.032282] ? setup_arch+0x835/0x954 [0.032284] ? start_kernel+0x5d/0x455 [0.032286] ? secondary_startup_64_no_verify+0xc2/0xcb efi_reserve_boot_services() has reserved memory of type EFI_BOOT_SERVICES_CODE & EFI_BOOT_SERVICES_DATA before crashkernel. efi_bgrt_init() assumes that EFI_BOOT_SERVICES_DATA is not reserved by other modules. Then, the e820_table is directly updated, and the BGRT memory is reserved. However, memblock_is_region_reserved() in efi_reserve_boot_services() returns true when the ranges only overlap. already_reserved = memblock_is_region_reserved(start, size); >>> >>> Do you mean efi_reserve_boot_services is supposed to reserve the bgrt >>> memory but it does not reserve it due to the region overlapping with >>> some other reserved region? If so can you debug and find what exact >>> memblock reserved region overlaps with the bgrt? >> >> Yes. I added the following debug print to efi_reserve_boot_services(): >> >> --- a/arch/x86/platform/efi/quirks.c >> +++ b/arch/x86/platform/efi/quirks.c >> @@ -339,6 +339,10 @@ void __init
Re: Question about Address Range Validation in Crash Kernel Allocation
Hi, On Fri, 22 Mar 2024 at 09:16, Baoquan He wrote: > > On 03/21/24 at 08:37pm, Li Huafei wrote: > > > > > > On 2024/3/21 18:06, Dave Young wrote: > > > Hi, > > > > > > On Thu, 21 Mar 2024 at 17:49, Li Huafei wrote: > > >> > > >> Hi Baoquan， > > >> > > >> On 2024/3/21 17:17, chenhaixiang (A) wrote: > > >>> > > > 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. > > >> > > >> We added dump_stack () printing in efi_mem_reserve () and found that > > >> [0x53cbd000-0x53cc] was reserved by BGRT: > > >> > > >> [0.032259] e820: update [mem 0x53cbd000-0x53cc] usable ==> > > >> reserved > > >> [0.032262] CPU: 0 PID: 0 Comm: swapper Not tainted > > >> 5.10.0-60.18.0.50.h820.eulerosv2r11.x86_64 #7 > > >> [0.032263] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 8.25 > > >> 08/30/2022 > > >> [0.032264] Call Trace: > > >> [0.032265] ? dump_stack+0x57/0x6e > > >> [0.032267] ? bgrt_init+0xc2/0xc2 > > >> [0.032268] ? __e820__range_update+0x7a/0x1d6 > > >> [0.032270] ? bgrt_init+0xc2/0xc2 > > >> [0.032272] ? bgrt_init+0xc2/0xc2 > > >> [0.032274] ? efi_arch_mem_reserve+0x1a3/0x1d0 > > >> [0.032276] ? efi_mem_reserve+0x2d/0x42 > > >> [0.032278] ? acpi_parse_bgrt+0xa/0x11 > > >> [0.032279] ? acpi_table_parse+0x86/0xbc > > >> [0.032281] ? acpi_boot_init+0x79/0xad > > >> [0.032282] ? setup_arch+0x835/0x954 > > >> [0.032284] ? start_kernel+0x5d/0x455 > > >> [0.032286] ? secondary_startup_64_no_verify+0xc2/0xcb > > >> > > >> efi_reserve_boot_services() has reserved memory of type > > >> EFI_BOOT_SERVICES_CODE & EFI_BOOT_SERVICES_DATA before crashkernel. > > >> efi_bgrt_init() assumes that EFI_BOOT_SERVICES_DATA is not reserved by > > >> other modules. Then, the e820_table is directly updated, and the BGRT > > >> memory is reserved. > > >> > > >> However, memblock_is_region_reserved() in efi_reserve_boot_services() > > >> returns true when the ranges only overlap. > > >> > > >> already_reserved = memblock_is_region_reserved(start, size); > > > > > > Do you mean efi_reserve_boot_services is supposed to reserve the bgrt > > > memory but it does not reserve it due to the region overlapping with > > > some other reserved region? If so can you debug and find what exact > > > memblock
Re: Question about Address Range Validation in Crash Kernel Allocation
On Thu, 21 Mar 2024 at 20:37, Li Huafei wrote: > > > > On 2024/3/21 18:06, Dave Young wrote: > > Hi, > > > > On Thu, 21 Mar 2024 at 17:49, Li Huafei wrote: > >> > >> Hi Baoquan， > >> > >> On 2024/3/21 17:17, chenhaixiang (A) wrote: > >>> > > 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. > >> > >> We added dump_stack () printing in efi_mem_reserve () and found that > >> [0x53cbd000-0x53cc] was reserved by BGRT: > >> > >> [0.032259] e820: update [mem 0x53cbd000-0x53cc] usable ==> > >> reserved > >> [0.032262] CPU: 0 PID: 0 Comm: swapper Not tainted > >> 5.10.0-60.18.0.50.h820.eulerosv2r11.x86_64 #7 > >> [0.032263] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 8.25 > >> 08/30/2022 > >> [0.032264] Call Trace: > >> [0.032265] ? dump_stack+0x57/0x6e > >> [0.032267] ? bgrt_init+0xc2/0xc2 > >> [0.032268] ? __e820__range_update+0x7a/0x1d6 > >> [0.032270] ? bgrt_init+0xc2/0xc2 > >> [0.032272] ? bgrt_init+0xc2/0xc2 > >> [0.032274] ? efi_arch_mem_reserve+0x1a3/0x1d0 > >> [0.032276] ? efi_mem_reserve+0x2d/0x42 > >> [0.032278] ? acpi_parse_bgrt+0xa/0x11 > >> [0.032279] ? acpi_table_parse+0x86/0xbc > >> [0.032281] ? acpi_boot_init+0x79/0xad > >> [0.032282] ? setup_arch+0x835/0x954 > >> [0.032284] ? start_kernel+0x5d/0x455 > >> [0.032286] ? secondary_startup_64_no_verify+0xc2/0xcb > >> > >> efi_reserve_boot_services() has reserved memory of type > >> EFI_BOOT_SERVICES_CODE & EFI_BOOT_SERVICES_DATA before crashkernel. > >> efi_bgrt_init() assumes that EFI_BOOT_SERVICES_DATA is not reserved by > >> other modules. Then, the e820_table is directly updated, and the BGRT > >> memory is reserved. > >> > >> However, memblock_is_region_reserved() in efi_reserve_boot_services() > >> returns true when the ranges only overlap. > >> > >> already_reserved = memblock_is_region_reserved(start, size); > > > > Do you mean efi_reserve_boot_services is supposed to reserve the bgrt > > memory but it does not reserve it due to the region overlapping with > > some other reserved region? If so can you debug and find what exact > > memblock reserved region overlaps with the bgrt? > > Yes. I added the following debug print to efi_reserve_boot_services(): > > --- a/arch/x86/platform/efi/quirks.c > +++ b/arch/x86/platform/efi/quirks.c > @@ -339,6 +339,10 @@ void __init efi_reserve_boot_services(void) > > already_reserved =
Re: Question about Address Range Validation in Crash Kernel Allocation
On 03/21/24 at 08:37pm, Li Huafei wrote: > > > On 2024/3/21 18:06, Dave Young wrote: > > Hi, > > > > On Thu, 21 Mar 2024 at 17:49, Li Huafei wrote: > >> > >> Hi Baoquan， > >> > >> On 2024/3/21 17:17, chenhaixiang (A) wrote: > >>> > > 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. > >> > >> We added dump_stack () printing in efi_mem_reserve () and found that > >> [0x53cbd000-0x53cc] was reserved by BGRT: > >> > >> [0.032259] e820: update [mem 0x53cbd000-0x53cc] usable ==> > >> reserved > >> [0.032262] CPU: 0 PID: 0 Comm: swapper Not tainted > >> 5.10.0-60.18.0.50.h820.eulerosv2r11.x86_64 #7 > >> [0.032263] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 8.25 > >> 08/30/2022 > >> [0.032264] Call Trace: > >> [0.032265] ? dump_stack+0x57/0x6e > >> [0.032267] ? bgrt_init+0xc2/0xc2 > >> [0.032268] ? __e820__range_update+0x7a/0x1d6 > >> [0.032270] ? bgrt_init+0xc2/0xc2 > >> [0.032272] ? bgrt_init+0xc2/0xc2 > >> [0.032274] ? efi_arch_mem_reserve+0x1a3/0x1d0 > >> [0.032276] ? efi_mem_reserve+0x2d/0x42 > >> [0.032278] ? acpi_parse_bgrt+0xa/0x11 > >> [0.032279] ? acpi_table_parse+0x86/0xbc > >> [0.032281] ? acpi_boot_init+0x79/0xad > >> [0.032282] ? setup_arch+0x835/0x954 > >> [0.032284] ? start_kernel+0x5d/0x455 > >> [0.032286] ? secondary_startup_64_no_verify+0xc2/0xcb > >> > >> efi_reserve_boot_services() has reserved memory of type > >> EFI_BOOT_SERVICES_CODE & EFI_BOOT_SERVICES_DATA before crashkernel. > >> efi_bgrt_init() assumes that EFI_BOOT_SERVICES_DATA is not reserved by > >> other modules. Then, the e820_table is directly updated, and the BGRT > >> memory is reserved. > >> > >> However, memblock_is_region_reserved() in efi_reserve_boot_services() > >> returns true when the ranges only overlap. > >> > >> already_reserved = memblock_is_region_reserved(start, size); > > > > Do you mean efi_reserve_boot_services is supposed to reserve the bgrt > > memory but it does not reserve it due to the region overlapping with > > some other reserved region? If so can you debug and find what exact > > memblock reserved region overlaps with the bgrt? > > Yes. I added the following debug print to efi_reserve_boot_services(): > > --- a/arch/x86/platform/efi/quirks.c > +++ b/arch/x86/platform/efi/quirks.c > @@ -339,6 +339,10 @@ void __init efi_reserve_boot_services(void) > > already_reserved =
Re: Question about Address Range Validation in Crash Kernel Allocation
On 2024/3/21 18:06, Dave Young wrote:
> Hi,
>
> On Thu, 21 Mar 2024 at 17:49, Li Huafei wrote:
>>
>> Hi Baoquan，
>>
>> On 2024/3/21 17:17, chenhaixiang (A) wrote:
>>>
> 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.
>>
>> We added dump_stack () printing in efi_mem_reserve () and found that
>> [0x53cbd000-0x53cc] was reserved by BGRT:
>>
>> [0.032259] e820: update [mem 0x53cbd000-0x53cc] usable ==>
>> reserved
>> [0.032262] CPU: 0 PID: 0 Comm: swapper Not tainted
>> 5.10.0-60.18.0.50.h820.eulerosv2r11.x86_64 #7
>> [0.032263] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 8.25
>> 08/30/2022
>> [0.032264] Call Trace:
>> [0.032265] ? dump_stack+0x57/0x6e
>> [0.032267] ? bgrt_init+0xc2/0xc2
>> [0.032268] ? __e820__range_update+0x7a/0x1d6
>> [0.032270] ? bgrt_init+0xc2/0xc2
>> [0.032272] ? bgrt_init+0xc2/0xc2
>> [0.032274] ? efi_arch_mem_reserve+0x1a3/0x1d0
>> [0.032276] ? efi_mem_reserve+0x2d/0x42
>> [0.032278] ? acpi_parse_bgrt+0xa/0x11
>> [0.032279] ? acpi_table_parse+0x86/0xbc
>> [0.032281] ? acpi_boot_init+0x79/0xad
>> [0.032282] ? setup_arch+0x835/0x954
>> [0.032284] ? start_kernel+0x5d/0x455
>> [0.032286] ? secondary_startup_64_no_verify+0xc2/0xcb
>>
>> efi_reserve_boot_services() has reserved memory of type
>> EFI_BOOT_SERVICES_CODE & EFI_BOOT_SERVICES_DATA before crashkernel.
>> efi_bgrt_init() assumes that EFI_BOOT_SERVICES_DATA is not reserved by
>> other modules. Then, the e820_table is directly updated, and the BGRT
>> memory is reserved.
>>
>> However, memblock_is_region_reserved() in efi_reserve_boot_services()
>> returns true when the ranges only overlap.
>>
>> already_reserved = memblock_is_region_reserved(start, size);
>
> Do you mean efi_reserve_boot_services is supposed to reserve the bgrt
> memory but it does not reserve it due to the region overlapping with
> some other reserved region? If so can you debug and find what exact
> memblock reserved region overlaps with the bgrt?
Yes. I added the following debug print to efi_reserve_boot_services():
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -339,6 +339,10 @@ void __init efi_reserve_boot_services(void)
already_reserved = memblock_is_region_reserved(start, size);
+ pr_info("kdumpdebug: efi_reserve_boot_services start 0x%lu, "
+ "size 0x%lx, type 0x%lx, already_reserved %d\n",
+ start, size, md->type, already_reserved);
+
/*
*
Re: Question about Address Range Validation in Crash Kernel Allocation
Hi, On Thu, 21 Mar 2024 at 17:49, Li Huafei wrote: > > Hi Baoquan， > > On 2024/3/21 17:17, chenhaixiang (A) wrote: > > > >>> 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. > > We added dump_stack () printing in efi_mem_reserve () and found that > [0x53cbd000-0x53cc] was reserved by BGRT: > > [0.032259] e820: update [mem 0x53cbd000-0x53cc] usable ==> > reserved > [0.032262] CPU: 0 PID: 0 Comm: swapper Not tainted > 5.10.0-60.18.0.50.h820.eulerosv2r11.x86_64 #7 > [0.032263] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 8.25 > 08/30/2022 > [0.032264] Call Trace: > [0.032265] ? dump_stack+0x57/0x6e > [0.032267] ? bgrt_init+0xc2/0xc2 > [0.032268] ? __e820__range_update+0x7a/0x1d6 > [0.032270] ? bgrt_init+0xc2/0xc2 > [0.032272] ? bgrt_init+0xc2/0xc2 > [0.032274] ? efi_arch_mem_reserve+0x1a3/0x1d0 > [0.032276] ? efi_mem_reserve+0x2d/0x42 > [0.032278] ? acpi_parse_bgrt+0xa/0x11 > [0.032279] ? acpi_table_parse+0x86/0xbc > [0.032281] ? acpi_boot_init+0x79/0xad > [0.032282] ? setup_arch+0x835/0x954 > [0.032284] ? start_kernel+0x5d/0x455 > [0.032286] ? secondary_startup_64_no_verify+0xc2/0xcb > > efi_reserve_boot_services() has reserved memory of type > EFI_BOOT_SERVICES_CODE & EFI_BOOT_SERVICES_DATA before crashkernel. > efi_bgrt_init() assumes that EFI_BOOT_SERVICES_DATA is not reserved by > other modules. Then, the e820_table is directly updated, and the BGRT > memory is reserved. > > However, memblock_is_region_reserved() in efi_reserve_boot_services() > returns true when the ranges only overlap. > > already_reserved = memblock_is_region_reserved(start, size); Do you mean efi_reserve_boot_services is supposed to reserve the bgrt memory but it does not reserve it due to the region overlapping with some other reserved region? If so can you debug and find what exact memblock reserved region overlaps with the bgrt? BTW, the previous email threads are weird, and not threading correctly, hard to find information. > > /* > * Because the following memblock_reserve() is paired > * with memblock_free_late() for this region in > * efi_free_boot_services(), we must be extremely > * careful not to reserve, and subsequently free, > * critical regions of memory (like the kernel image) or > * those regions that somebody else has already > * reserved. > * > * A good example of a critical region that must not be > * freed is page zero (first 4Kb of memory), which may > * contain boot services
Re: Question about Address Range Validation in Crash Kernel Allocation
Hi Baoquan，
On 2024/3/21 17:17, chenhaixiang (A) wrote:
>
>>> 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.
We added dump_stack () printing in efi_mem_reserve () and found that
[0x53cbd000-0x53cc] was reserved by BGRT:
[0.032259] e820: update [mem 0x53cbd000-0x53cc] usable ==>
reserved
[0.032262] CPU: 0 PID: 0 Comm: swapper Not tainted
5.10.0-60.18.0.50.h820.eulerosv2r11.x86_64 #7
[0.032263] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 8.25
08/30/2022
[0.032264] Call Trace:
[0.032265] ? dump_stack+0x57/0x6e
[0.032267] ? bgrt_init+0xc2/0xc2
[0.032268] ? __e820__range_update+0x7a/0x1d6
[0.032270] ? bgrt_init+0xc2/0xc2
[0.032272] ? bgrt_init+0xc2/0xc2
[0.032274] ? efi_arch_mem_reserve+0x1a3/0x1d0
[0.032276] ? efi_mem_reserve+0x2d/0x42
[0.032278] ? acpi_parse_bgrt+0xa/0x11
[0.032279] ? acpi_table_parse+0x86/0xbc
[0.032281] ? acpi_boot_init+0x79/0xad
[0.032282] ? setup_arch+0x835/0x954
[0.032284] ? start_kernel+0x5d/0x455
[0.032286] ? secondary_startup_64_no_verify+0xc2/0xcb
efi_reserve_boot_services() has reserved memory of type
EFI_BOOT_SERVICES_CODE & EFI_BOOT_SERVICES_DATA before crashkernel.
efi_bgrt_init() assumes that EFI_BOOT_SERVICES_DATA is not reserved by
other modules. Then, the e820_table is directly updated, and the BGRT
memory is reserved.
However, memblock_is_region_reserved() in efi_reserve_boot_services()
returns true when the ranges only overlap.
already_reserved = memblock_is_region_reserved(start, size);
/*
* Because the following memblock_reserve() is paired
* with memblock_free_late() for this region in
* efi_free_boot_services(), we must be extremely
* careful not to reserve, and subsequently free,
* critical regions of memory (like the kernel image) or
* those regions that somebody else has already
* reserved.
*
* A good example of a critical region that must not be
* freed is page zero (first 4Kb of memory), which may
* contain boot services code/data but is marked
* E820_TYPE_RESERVED by trim_bios_range().
*/
if (!already_reserved) {
memblock_reserve(start, size);
/*
* If we are the first to reserve the region, no
* one else cares about it. We own it and can
* free it later.
*/
if (can_free_region(start, size))
continue;
}
As a result, some memory of EFI_BOOT_SERVICES_DATA is not reserved in
advance. The subsequent crashkernel happens to reserve this portion of
memory, which conflicts with BGRT.
> Current
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
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.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. 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 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
On 03/20/24 at 01:12pm, chenhaixiang (A) wrote: > 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. Yeah, please attach the complete log. I will have a look. ___ 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)
> > > > 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
> > > >
Re: Question about Address Range Validation in Crash Kernel Allocation
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.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
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
Re: Question about Address Range Validation in Crash Kernel Allocation
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
