Re: [PATCH bpf-next v2] bpf: fix warning for crash_kexec
On Tue, Mar 19, 2024 at 1:02 AM Hari Bathini wrote:
>
> With [1], crash dump specific code is moved out of CONFIG_KEXEC_CORE
> and placed under CONFIG_CRASH_DUMP, where it is more appropriate.
> And since CONFIG_KEXEC & !CONFIG_CRASH_DUMP build option is supported
> with that, it led to the below warning:
>
> "WARN: resolve_btfids: unresolved symbol crash_kexec"
>
> Fix it by using the appropriate #ifdef.
>
> [1] https://lore.kernel.org/all/20240124051254.67105-1-...@redhat.com/
>
> Acked-by: Baoquan He
> Fixes: 29fd9ae62910 ("crash: split crash dumping code out from kexec_core.c")
I don't think either bpf or bpf-next have this commit just yet, so
landing it in the bpf/bpf-next tree doesn't make much sense. It
probably would be best to land it through the tree which does the
CONFIG_KEXEC_CORE -> CONFIG_CRASH_DUMP change in kernel/Makefile.
pw-bot: cr
> Acked-by: Jiri Olsa
> Acked-by: Stanislav Fomichev
> Signed-off-by: Hari Bathini
> ---
>
> Changes in v2:
> * Updated changelog.
> * Added Fixes and Acked-by tags.
>
>
> kernel/bpf/helpers.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index a89587859571..449b9a5d3fe3 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2548,7 +2548,7 @@ __bpf_kfunc void bpf_throw(u64 cookie)
> __bpf_kfunc_end_defs();
>
> BTF_KFUNCS_START(generic_btf_ids)
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_CRASH_DUMP
> BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE)
> #endif
> BTF_ID_FLAGS(func, bpf_obj_new_impl, KF_ACQUIRE | KF_RET_NULL)
> --
> 2.44.0
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [bug report] WARNING: CPU: 0 PID: 1 at kernel/resource.c:834 __insert_resource+0x84/0x110
On 03/19/24 at 01:59pm, Ilpo Järvinen wrote: > On Tue, 19 Mar 2024, Changhui Zhong wrote: > > > Hello, > > > > found a kernel warning issue at "kernel/resource.c:834 > > __insert_resource+0x84/0x110" ,please help check, > > > > repo:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > branch: master > > commit HEAD:f6cef5f8c37f58a3bc95b3754c3ae98e086631ca > > > > [0.130164] [ cut here ] > > [0.130370] WARNING: CPU: 0 PID: 1 at kernel/resource.c:834 > > __insert_resource+0x84/0x110 > > [0.131364] Modules linked in: > > [0.132364] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0+ #1 > > [0.133365] Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS > > 2.15.1 06/15/2022 > > [0.134364] RIP: 0010:__insert_resource+0x84/0x110 > > [0.135364] Code: d0 4c 39 c1 76 b1 c3 cc cc cc cc 4c 8d 4a 30 48 > > 8b 52 30 48 85 d2 75 b7 48 89 56 30 49 89 31 48 89 46 28 31 c0 c3 cc > > cc cc cc <0f> 0b 48 89 d0 c3 cc cc cc cc 49 89 d2 eb 1a 4d 39 42 08 77 > > 19 4d > > [0.136363] RSP: :b257400dfe08 EFLAGS: 00010246 > > [0.137363] RAX: 9e147ffca640 RBX: RCX: > > 2600 > > [0.138363] RDX: 86c45ee0 RSI: 86c45ee0 RDI: > > 2600 > > [0.139363] RBP: 8684d120 R08: 35ff R09: > > 35ff > > [0.140363] R10: 2f31646f R11: 59a7ffee R12: > > 86c45ee0 > > [0.141363] R13: R14: R15: > > > > [0.142363] FS: () GS:9e127780() > > knlGS: > > [0.143363] CS: 0010 DS: ES: CR0: 80050033 > > [0.144363] CR2: 9e1333601000 CR3: 000332220001 CR4: > > 007706f0 > > [0.145363] DR0: DR1: DR2: > > > > [0.146363] DR3: DR6: fffe0ff0 DR7: > > 0400 > > [0.147363] PKRU: 5554 > > [0.148363] Call Trace: > > [0.149364] > > [0.150365] ? __warn+0x7f/0x130 > > [0.151363] ? __insert_resource+0x84/0x110 > > [0.152364] ? report_bug+0x18a/0x1a0 > > [0.153364] ? handle_bug+0x3c/0x70 > > [0.154363] ? exc_invalid_op+0x14/0x70 > > [0.155363] ? asm_exc_invalid_op+0x16/0x20 > > [0.156364] ? __insert_resource+0x84/0x110 > > [0.157364] ? add_device_randomness+0x75/0xa0 > > [0.158363] insert_resource+0x26/0x50 > > [0.159364] ? __pfx_insert_crashkernel_resources+0x10/0x10 > > [0.160363] insert_crashkernel_resources+0x62/0x70 > > Hi, > > This seems related to crashkernel stuff, I added a few Ccs related to > it. > > I don't know why you sent this only to linux-pci list as it seems likely > to be entirely unrelated to PCI. Too few info is provided. I guess this is happening on x86_64. Do you have the kernel config, and what kernel you are testing? What operation are you taking to trigger this? Below commit could be suspect, but not sure if it's the real criminal. commit 4a693ce65b186fddc1a73621bd6f941e6e3eca21 Author: Huacai Chen Date: Fri Dec 29 16:02:13 2023 +0800 kdump: defer the insertion of crashkernel resources Dave reported a similar one, he did kexec reboot firstly, then in 2nd kernel crashkernel reservation will trigger the iomem inserting error. [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 Can you try Dave's patch firstly? If it doesn't work, try reverting above Huacai's patch? it may need manual editing. > > -- > i. > > > [0.161365] do_one_initcall+0x41/0x300 > > [0.162364] kernel_init_freeable+0x21e/0x320 > > [0.163365] ? __pfx_kernel_init+0x10/0x10 > > [0.164364] kernel_init+0x16/0x1c0 > > [0.165364] ret_from_fork+0x2d/0x50 > > [0.166364] ? __pfx_kernel_init+0x10/0x10 > > [0.167363] ret_from_fork_asm+0x1a/0x30 > > [0.168365] > > [0.169363] ---[ end trace ]--- > > > > Thanks, > > > > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [bug report] WARNING: CPU: 0 PID: 1 at kernel/resource.c:834 __insert_resource+0x84/0x110
Hi，Ilpo thanks for your reply, I didn't know which mailing list I should report this issue to, and then I searched and saw that there was a patch about kernel/resource.c in the linux-pci mailing list, so I reported it here. Thanks， On Tue, Mar 19, 2024 at 8:00 PM Ilpo Järvinen wrote: > > On Tue, 19 Mar 2024, Changhui Zhong wrote: > > > Hello, > > > > found a kernel warning issue at "kernel/resource.c:834 > > __insert_resource+0x84/0x110" ,please help check, > > > > repo:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > branch: master > > commit HEAD:f6cef5f8c37f58a3bc95b3754c3ae98e086631ca > > > > [0.130164] [ cut here ] > > [0.130370] WARNING: CPU: 0 PID: 1 at kernel/resource.c:834 > > __insert_resource+0x84/0x110 > > [0.131364] Modules linked in: > > [0.132364] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0+ #1 > > [0.133365] Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS > > 2.15.1 06/15/2022 > > [0.134364] RIP: 0010:__insert_resource+0x84/0x110 > > [0.135364] Code: d0 4c 39 c1 76 b1 c3 cc cc cc cc 4c 8d 4a 30 48 > > 8b 52 30 48 85 d2 75 b7 48 89 56 30 49 89 31 48 89 46 28 31 c0 c3 cc > > cc cc cc <0f> 0b 48 89 d0 c3 cc cc cc cc 49 89 d2 eb 1a 4d 39 42 08 77 > > 19 4d > > [0.136363] RSP: :b257400dfe08 EFLAGS: 00010246 > > [0.137363] RAX: 9e147ffca640 RBX: RCX: > > 2600 > > [0.138363] RDX: 86c45ee0 RSI: 86c45ee0 RDI: > > 2600 > > [0.139363] RBP: 8684d120 R08: 35ff R09: > > 35ff > > [0.140363] R10: 2f31646f R11: 59a7ffee R12: > > 86c45ee0 > > [0.141363] R13: R14: R15: > > > > [0.142363] FS: () GS:9e127780() > > knlGS: > > [0.143363] CS: 0010 DS: ES: CR0: 80050033 > > [0.144363] CR2: 9e1333601000 CR3: 000332220001 CR4: > > 007706f0 > > [0.145363] DR0: DR1: DR2: > > > > [0.146363] DR3: DR6: fffe0ff0 DR7: > > 0400 > > [0.147363] PKRU: 5554 > > [0.148363] Call Trace: > > [0.149364] > > [0.150365] ? __warn+0x7f/0x130 > > [0.151363] ? __insert_resource+0x84/0x110 > > [0.152364] ? report_bug+0x18a/0x1a0 > > [0.153364] ? handle_bug+0x3c/0x70 > > [0.154363] ? exc_invalid_op+0x14/0x70 > > [0.155363] ? asm_exc_invalid_op+0x16/0x20 > > [0.156364] ? __insert_resource+0x84/0x110 > > [0.157364] ? add_device_randomness+0x75/0xa0 > > [0.158363] insert_resource+0x26/0x50 > > [0.159364] ? __pfx_insert_crashkernel_resources+0x10/0x10 > > [0.160363] insert_crashkernel_resources+0x62/0x70 > > Hi, > > This seems related to crashkernel stuff, I added a few Ccs related to > it. > > I don't know why you sent this only to linux-pci list as it seems likely > to be entirely unrelated to PCI. > > -- > i. > > > [0.161365] do_one_initcall+0x41/0x300 > > [0.162364] kernel_init_freeable+0x21e/0x320 > > [0.163365] ? __pfx_kernel_init+0x10/0x10 > > [0.164364] kernel_init+0x16/0x1c0 > > [0.165364] ret_from_fork+0x2d/0x50 > > [0.166364] ? __pfx_kernel_init+0x10/0x10 > > [0.167363] ret_from_fork_asm+0x1a/0x30 > > [0.168365] > > [0.169363] ---[ end trace ]--- > > > > Thanks, > > > > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [bug report] WARNING: CPU: 0 PID: 1 at kernel/resource.c:834 __insert_resource+0x84/0x110
On Tue, 19 Mar 2024, Changhui Zhong wrote: > Hello, > > found a kernel warning issue at "kernel/resource.c:834 > __insert_resource+0x84/0x110" ,please help check, > > repo:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > branch: master > commit HEAD:f6cef5f8c37f58a3bc95b3754c3ae98e086631ca > > [0.130164] [ cut here ] > [0.130370] WARNING: CPU: 0 PID: 1 at kernel/resource.c:834 > __insert_resource+0x84/0x110 > [0.131364] Modules linked in: > [0.132364] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0+ #1 > [0.133365] Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS > 2.15.1 06/15/2022 > [0.134364] RIP: 0010:__insert_resource+0x84/0x110 > [0.135364] Code: d0 4c 39 c1 76 b1 c3 cc cc cc cc 4c 8d 4a 30 48 > 8b 52 30 48 85 d2 75 b7 48 89 56 30 49 89 31 48 89 46 28 31 c0 c3 cc > cc cc cc <0f> 0b 48 89 d0 c3 cc cc cc cc 49 89 d2 eb 1a 4d 39 42 08 77 > 19 4d > [0.136363] RSP: :b257400dfe08 EFLAGS: 00010246 > [0.137363] RAX: 9e147ffca640 RBX: RCX: > 2600 > [0.138363] RDX: 86c45ee0 RSI: 86c45ee0 RDI: > 2600 > [0.139363] RBP: 8684d120 R08: 35ff R09: > 35ff > [0.140363] R10: 2f31646f R11: 59a7ffee R12: > 86c45ee0 > [0.141363] R13: R14: R15: > > [0.142363] FS: () GS:9e127780() > knlGS: > [0.143363] CS: 0010 DS: ES: CR0: 80050033 > [0.144363] CR2: 9e1333601000 CR3: 000332220001 CR4: > 007706f0 > [0.145363] DR0: DR1: DR2: > > [0.146363] DR3: DR6: fffe0ff0 DR7: > 0400 > [0.147363] PKRU: 5554 > [0.148363] Call Trace: > [0.149364] > [0.150365] ? __warn+0x7f/0x130 > [0.151363] ? __insert_resource+0x84/0x110 > [0.152364] ? report_bug+0x18a/0x1a0 > [0.153364] ? handle_bug+0x3c/0x70 > [0.154363] ? exc_invalid_op+0x14/0x70 > [0.155363] ? asm_exc_invalid_op+0x16/0x20 > [0.156364] ? __insert_resource+0x84/0x110 > [0.157364] ? add_device_randomness+0x75/0xa0 > [0.158363] insert_resource+0x26/0x50 > [0.159364] ? __pfx_insert_crashkernel_resources+0x10/0x10 > [0.160363] insert_crashkernel_resources+0x62/0x70 Hi, This seems related to crashkernel stuff, I added a few Ccs related to it. I don't know why you sent this only to linux-pci list as it seems likely to be entirely unrelated to PCI. -- i. > [0.161365] do_one_initcall+0x41/0x300 > [0.162364] kernel_init_freeable+0x21e/0x320 > [0.163365] ? __pfx_kernel_init+0x10/0x10 > [0.164364] kernel_init+0x16/0x1c0 > [0.165364] ret_from_fork+0x2d/0x50 > [0.166364] ? __pfx_kernel_init+0x10/0x10 > [0.167363] ret_from_fork_asm+0x1a/0x30 > [0.168365] > [0.169363] ---[ end trace ]--- > > Thanks, > > ___ 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/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: [PATCH linux-next] bpf: fix warning for crash_kexec
On 18/03/24 9:43 pm, Yonghong Song wrote: On 3/17/24 11:52 PM, Hari Bathini wrote: Just checking on whether this will go via bpf or mm tree? Sending to bpf-next should be okay. Could you resubmit the patch as CONFIG_CRASH_DUMP probably not available to bpf-next when you initially submitted the patch. OK. Sent V2 with tags added and changelog updated: https://lore.kernel.org/all/20240319080152.36987-1-hbath...@linux.ibm.com/ On 09/02/24 6:05 pm, Hari Bathini wrote: With [1], CONFIG_KEXEC & !CONFIG_CRASH_DUMP is supported but that led to the below warning: "WARN: resolve_btfids: unresolved symbol crash_kexec" Fix it by using the appropriate #ifdef. [1] https://lore.kernel.org/all/20240124051254.67105-1-...@redhat.com/ Signed-off-by: Hari Bathini --- kernel/bpf/helpers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index 4db1c658254c..e408d1115e26 100644 --- a/kernel/bpf/helpers.c +++ b/kernel/bpf/helpers.c @@ -2545,7 +2545,7 @@ __bpf_kfunc void bpf_throw(u64 cookie) __bpf_kfunc_end_defs(); BTF_KFUNCS_START(generic_btf_ids) -#ifdef CONFIG_KEXEC_CORE +#ifdef CONFIG_CRASH_DUMP BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE) #endif BTF_ID_FLAGS(func, bpf_obj_new_impl, KF_ACQUIRE | KF_RET_NULL) ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH bpf-next v2] bpf: fix warning for crash_kexec
With [1], crash dump specific code is moved out of CONFIG_KEXEC_CORE
and placed under CONFIG_CRASH_DUMP, where it is more appropriate.
And since CONFIG_KEXEC & !CONFIG_CRASH_DUMP build option is supported
with that, it led to the below warning:
"WARN: resolve_btfids: unresolved symbol crash_kexec"
Fix it by using the appropriate #ifdef.
[1] https://lore.kernel.org/all/20240124051254.67105-1-...@redhat.com/
Acked-by: Baoquan He
Fixes: 29fd9ae62910 ("crash: split crash dumping code out from kexec_core.c")
Acked-by: Jiri Olsa
Acked-by: Stanislav Fomichev
Signed-off-by: Hari Bathini
---
Changes in v2:
* Updated changelog.
* Added Fixes and Acked-by tags.
kernel/bpf/helpers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index a89587859571..449b9a5d3fe3 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -2548,7 +2548,7 @@ __bpf_kfunc void bpf_throw(u64 cookie)
__bpf_kfunc_end_defs();
BTF_KFUNCS_START(generic_btf_ids)
-#ifdef CONFIG_KEXEC_CORE
+#ifdef CONFIG_CRASH_DUMP
BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE)
#endif
BTF_ID_FLAGS(func, bpf_obj_new_impl, KF_ACQUIRE | KF_RET_NULL)
--
2.44.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
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
