[PATCH] vmcoreinfo: export SECTION_HAS_MEM_MAP

[PATCH] vmcoreinfo: export SECTION_HAS_MEM_MAP

[David Hildenbrand (Arm)]

The crash tool currently hardcodes SECTION_HAS_MEM_MAP, and makedumpfile
needs similar information (although still relying on
SECTION_MARKED_PRESENT, it should switch to SECTION_HAS_MEM_MAP).

Let's just export the value instead, so tools that work on vmcoreinfo
will not have to guess.

Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
Result of the discussion in reply to "[PATCH v2 00/13] mm/sparse: remove
SECTION_MARKED_PRESENT and further cleanups" [1]

This patch can go in independently. It would be preferable if both
go into the same kernel release ;)

[1] https://lore.kernel.org/r/20260921-b4-sparsemem_cleanups-v2-0-54d81d65e125@kernel.org 
---
 kernel/vmcore_info.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
index 5a417f8a922a..7833a36064a8 100644
--- a/kernel/vmcore_info.c
+++ b/kernel/vmcore_info.c
@@ -182,6 +182,7 @@ static int __init crash_save_vmcoreinfo_init(void)
 	VMCOREINFO_STRUCT_SIZE(mem_section);
 	VMCOREINFO_OFFSET(mem_section, section_mem_map);
 	VMCOREINFO_NUMBER(SECTION_SIZE_BITS);
+	VMCOREINFO_NUMBER(SECTION_HAS_MEM_MAP);
 	VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
 #endif
 	VMCOREINFO_STRUCT_SIZE(page);

---

base-commit: 57e4ac91fc62d75d84b5a03827a19ceb4094ecd9

change-id: 20260928-section_has_mem_map-6205dc90a09f

--

Cheers,

David

Re: [PATCH] vmcoreinfo: export SECTION_HAS_MEM_MAP

[Baoquan He]

On 09/28/26 at 10:48am, David Hildenbrand (Arm) wrote:
> The crash tool currently hardcodes SECTION_HAS_MEM_MAP, and makedumpfile
> needs similar information (although still relying on
> SECTION_MARKED_PRESENT, it should switch to SECTION_HAS_MEM_MAP).
> 
> Let's just export the value instead, so tools that work on vmcoreinfo
> will not have to guess.
> 
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
> Result of the discussion in reply to "[PATCH v2 00/13] mm/sparse: remove
> SECTION_MARKED_PRESENT and further cleanups" [1]
> 
> This patch can go in independently. It would be preferable if both
> go into the same kernel release ;)
> 
> [1] https://lore.kernel.org/r/20260921-b4-sparsemem_cleanups-v2-0-54d81d65e125@kernel.org 
> ---
>  kernel/vmcore_info.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
> index 5a417f8a922a..7833a36064a8 100644
> --- a/kernel/vmcore_info.c
> +++ b/kernel/vmcore_info.c
> @@ -182,6 +182,7 @@ static int __init crash_save_vmcoreinfo_init(void)
>  	VMCOREINFO_STRUCT_SIZE(mem_section);
>  	VMCOREINFO_OFFSET(mem_section, section_mem_map);
>  	VMCOREINFO_NUMBER(SECTION_SIZE_BITS);
> +	VMCOREINFO_NUMBER(SECTION_HAS_MEM_MAP);
>  	VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
>  #endif
>  	VMCOREINFO_STRUCT_SIZE(page);

It would be good to add one section in
Documentation/admin-guide/kdump/vmcoreinfo.rst, e.g

SECTION_HAS_MEM_MAP
-------------------

Indicates a memory section has struct page array (mem_map). User-space
tools should read this value but not hardcode it since the bit position
could change between kernel versions.

The code change looks good to me.

> 
> ---
> 
> base-commit: 57e4ac91fc62d75d84b5a03827a19ceb4094ecd9
> 
> change-id: 20260928-section_has_mem_map-6205dc90a09f
> 
> --
> 
> Cheers,
> 
> David
> 

Re: [PATCH] vmcoreinfo: export SECTION_HAS_MEM_MAP

[David Hildenbrand (Arm)]

On 9/28/26 11:11, Baoquan He wrote:
> On 09/28/26 at 10:48am, David Hildenbrand (Arm) wrote:
>> The crash tool currently hardcodes SECTION_HAS_MEM_MAP, and makedumpfile
>> needs similar information (although still relying on
>> SECTION_MARKED_PRESENT, it should switch to SECTION_HAS_MEM_MAP).
>>
>> Let's just export the value instead, so tools that work on vmcoreinfo
>> will not have to guess.
>>
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>> ---
>> Result of the discussion in reply to "[PATCH v2 00/13] mm/sparse: remove
>> SECTION_MARKED_PRESENT and further cleanups" [1]
>>
>> This patch can go in independently. It would be preferable if both
>> go into the same kernel release ;)
>>
>> [1] https://lore.kernel.org/r/20260921-b4-sparsemem_cleanups-v2-0-54d81d65e125@kernel.org 
>> ---
>>  kernel/vmcore_info.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
>> index 5a417f8a922a..7833a36064a8 100644
>> --- a/kernel/vmcore_info.c
>> +++ b/kernel/vmcore_info.c
>> @@ -182,6 +182,7 @@ static int __init crash_save_vmcoreinfo_init(void)
>>  	VMCOREINFO_STRUCT_SIZE(mem_section);
>>  	VMCOREINFO_OFFSET(mem_section, section_mem_map);
>>  	VMCOREINFO_NUMBER(SECTION_SIZE_BITS);
>> +	VMCOREINFO_NUMBER(SECTION_HAS_MEM_MAP);
>>  	VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
>>  #endif
>>  	VMCOREINFO_STRUCT_SIZE(page);
> 
> It would be good to add one section in
> Documentation/admin-guide/kdump/vmcoreinfo.rst, e.g
> 
> SECTION_HAS_MEM_MAP
> -------------------
> 
> Indicates a memory section has struct page array (mem_map). User-space
> tools should read this value but not hardcode it since the bit position
> could change between kernel versions.

I'm not particularly happy about having core-kernel defines documented in
kdump/vmcoreinfo.rst, though?

If it would be something vmcoreinfo special, sure. But not for basic defines.

"See the kernel source code" is really what anybody using this should be doing?

-- 
Cheers,

David

Re: [PATCH] vmcoreinfo: export SECTION_HAS_MEM_MAP

[Baoquan He]

On 09/28/26 at 11:14am, David Hildenbrand (Arm) wrote:
> On 9/28/26 11:11, Baoquan He wrote:
> > On 09/28/26 at 10:48am, David Hildenbrand (Arm) wrote:
> >> The crash tool currently hardcodes SECTION_HAS_MEM_MAP, and makedumpfile
> >> needs similar information (although still relying on
> >> SECTION_MARKED_PRESENT, it should switch to SECTION_HAS_MEM_MAP).
> >>
> >> Let's just export the value instead, so tools that work on vmcoreinfo
> >> will not have to guess.
> >>
> >> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> >> ---
> >> Result of the discussion in reply to "[PATCH v2 00/13] mm/sparse: remove
> >> SECTION_MARKED_PRESENT and further cleanups" [1]
> >>
> >> This patch can go in independently. It would be preferable if both
> >> go into the same kernel release ;)
> >>
> >> [1] https://lore.kernel.org/r/20260921-b4-sparsemem_cleanups-v2-0-54d81d65e125@kernel.org 
> >> ---
> >>  kernel/vmcore_info.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
> >> index 5a417f8a922a..7833a36064a8 100644
> >> --- a/kernel/vmcore_info.c
> >> +++ b/kernel/vmcore_info.c
> >> @@ -182,6 +182,7 @@ static int __init crash_save_vmcoreinfo_init(void)
> >>  	VMCOREINFO_STRUCT_SIZE(mem_section);
> >>  	VMCOREINFO_OFFSET(mem_section, section_mem_map);
> >>  	VMCOREINFO_NUMBER(SECTION_SIZE_BITS);
> >> +	VMCOREINFO_NUMBER(SECTION_HAS_MEM_MAP);
> >>  	VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
> >>  #endif
> >>  	VMCOREINFO_STRUCT_SIZE(page);
> > 
> > It would be good to add one section in
> > Documentation/admin-guide/kdump/vmcoreinfo.rst, e.g
> > 
> > SECTION_HAS_MEM_MAP
> > -------------------
> > 
> > Indicates a memory section has struct page array (mem_map). User-space
> > tools should read this value but not hardcode it since the bit position
> > could change between kernel versions.
> 
> I'm not particularly happy about having core-kernel defines documented in
> kdump/vmcoreinfo.rst, though?
> 
> If it would be something vmcoreinfo special, sure. But not for basic defines.
> 
> "See the kernel source code" is really what anybody using this should be doing?

I can't remember who suggested adding this document. The benefit is
users can read document to understand how it works, no need to look
at the code. I don't have strong preference on this.

So I am fine with both. Or we can add it if anyone really complains.

For the patch itself,

Acked-by: Baoquan He <baoquan.he@linux.dev>

Thanks
Baoquan

Re: [PATCH] vmcoreinfo: export SECTION_HAS_MEM_MAP

[Dave Young]

On 9/28/26 4:48 PM, David Hildenbrand (Arm) wrote:
> The crash tool currently hardcodes SECTION_HAS_MEM_MAP, and makedumpfile
> needs similar information (although still relying on
> SECTION_MARKED_PRESENT, it should switch to SECTION_HAS_MEM_MAP).
> 
> Let's just export the value instead, so tools that work on vmcoreinfo
> will not have to guess.
> 
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
> Result of the discussion in reply to "[PATCH v2 00/13] mm/sparse: remove
> SECTION_MARKED_PRESENT and further cleanups" [1]
> 
> This patch can go in independently. It would be preferable if both
> go into the same kernel release ;)
> 
> [1] https://lore.kernel.org/r/20260921-b4-sparsemem_cleanups-v2-0-54d81d65e125@kernel.org 
> ---
>  kernel/vmcore_info.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
> index 5a417f8a922a..7833a36064a8 100644
> --- a/kernel/vmcore_info.c
> +++ b/kernel/vmcore_info.c
> @@ -182,6 +182,7 @@ static int __init crash_save_vmcoreinfo_init(void)
>  	VMCOREINFO_STRUCT_SIZE(mem_section);
>  	VMCOREINFO_OFFSET(mem_section, section_mem_map);
>  	VMCOREINFO_NUMBER(SECTION_SIZE_BITS);
> +	VMCOREINFO_NUMBER(SECTION_HAS_MEM_MAP);
>  	VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
>  #endif
>  	VMCOREINFO_STRUCT_SIZE(page);

Current crash code looks below:
#define SECTION_MARKED_PRESENT          (1UL<<0)
#define SECTION_HAS_MEM_MAP             (1UL<<1)
#define SECTION_IS_ONLINE               (1UL<<2)
#define SECTION_IS_EARLY                (1UL<<3)
#define SECTION_TAINT_ZONE_DEVICE       (1UL<<4)
#define SECTION_MAP_LAST_BIT            (1UL<<5)
#define SECTION_MAP_MASK                (~(SECTION_MAP_LAST_BIT-1))


And it does not match the kernel for below chunk with ifdef
#ifdef CONFIG_ZONE_DEVICE
        SECTION_TAINT_ZONE_DEVICE_BIT,
#endif
#ifdef CONFIG_SPARSEMEM_VMEMMAP_PREINIT
        SECTION_IS_VMEMMAP_PREINIT_BIT,
#endif

The last bit could be wrong in crash.  So all numbers should be exported in vmcoreinfo.

Thoughts?


ThanksDave

Re: [PATCH] vmcoreinfo: export SECTION_HAS_MEM_MAP

[David Hildenbrand (Arm)]

On 9/28/26 12:23, Dave Young wrote:
> On 9/28/26 4:48 PM, David Hildenbrand (Arm) wrote:
>> The crash tool currently hardcodes SECTION_HAS_MEM_MAP, and makedumpfile
>> needs similar information (although still relying on
>> SECTION_MARKED_PRESENT, it should switch to SECTION_HAS_MEM_MAP).
>>
>> Let's just export the value instead, so tools that work on vmcoreinfo
>> will not have to guess.
>>
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>> ---
>> Result of the discussion in reply to "[PATCH v2 00/13] mm/sparse: remove
>> SECTION_MARKED_PRESENT and further cleanups" [1]
>>
>> This patch can go in independently. It would be preferable if both
>> go into the same kernel release ;)
>>
>> [1] https://lore.kernel.org/r/20260921-b4-sparsemem_cleanups-v2-0-54d81d65e125@kernel.org 
>> ---
>>  kernel/vmcore_info.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
>> index 5a417f8a922a..7833a36064a8 100644
>> --- a/kernel/vmcore_info.c
>> +++ b/kernel/vmcore_info.c
>> @@ -182,6 +182,7 @@ static int __init crash_save_vmcoreinfo_init(void)
>>  	VMCOREINFO_STRUCT_SIZE(mem_section);
>>  	VMCOREINFO_OFFSET(mem_section, section_mem_map);
>>  	VMCOREINFO_NUMBER(SECTION_SIZE_BITS);
>> +	VMCOREINFO_NUMBER(SECTION_HAS_MEM_MAP);
>>  	VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
>>  #endif
>>  	VMCOREINFO_STRUCT_SIZE(page);
> 
> Current crash code looks below:
> #define SECTION_MARKED_PRESENT          (1UL<<0)
> #define SECTION_HAS_MEM_MAP             (1UL<<1)
> #define SECTION_IS_ONLINE               (1UL<<2)
> #define SECTION_IS_EARLY                (1UL<<3)
> #define SECTION_TAINT_ZONE_DEVICE       (1UL<<4)
> #define SECTION_MAP_LAST_BIT            (1UL<<5)
> #define SECTION_MAP_MASK                (~(SECTION_MAP_LAST_BIT-1))
> 
> 
> And it does not match the kernel for below chunk with ifdef
> #ifdef CONFIG_ZONE_DEVICE
>         SECTION_TAINT_ZONE_DEVICE_BIT,
> #endif
> #ifdef CONFIG_SPARSEMEM_VMEMMAP_PREINIT
>         SECTION_IS_VMEMMAP_PREINIT_BIT,
> #endif
> 
> The last bit could be wrong in crash.  So all numbers should be exported in vmcoreinfo.
> 
> Thoughts?

You know the crash code best, so likely ... it's time one of the crash people
takes over this patch?

-- 
Cheers,

David

Re: [PATCH] vmcoreinfo: export SECTION_HAS_MEM_MAP

[Bradley Morgan]

On 28 September 2026 09:48:21 BST, "David Hildenbrand (Arm)"
<david@kernel.org> wrote:
>The crash tool currently hardcodes SECTION_HAS_MEM_MAP, and makedumpfile
>needs similar information (although still relying on
>SECTION_MARKED_PRESENT, it should switch to SECTION_HAS_MEM_MAP).
>
>Let's just export the value instead, so tools that work on vmcoreinfo
>will not have to guess.

I guess that works

Reviewed-by: Bradley Morgan <brads@mainlining.org>


>
>Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>---
>Result of the discussion in reply to "[PATCH v2 00/13] mm/sparse: remove
>SECTION_MARKED_PRESENT and further cleanups" [1]
>
>This patch can go in independently. It would be preferable if both
>go into the same kernel release ;)
>
>[1]
>https://lore.kernel.org/r/20260921-b4-sparsemem_cleanups-v2-0-54d81d65e125@kernel.org
>---
> kernel/vmcore_info.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
>index 5a417f8a922a..7833a36064a8 100644
>--- a/kernel/vmcore_info.c
>+++ b/kernel/vmcore_info.c
>@@ -182,6 +182,7 @@ static int __init crash_save_vmcoreinfo_init(void)
> 	VMCOREINFO_STRUCT_SIZE(mem_section);
> 	VMCOREINFO_OFFSET(mem_section, section_mem_map);
> 	VMCOREINFO_NUMBER(SECTION_SIZE_BITS);
>+	VMCOREINFO_NUMBER(SECTION_HAS_MEM_MAP);
> 	VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS);
> #endif
> 	VMCOREINFO_STRUCT_SIZE(page);
>
>---
>
>base-commit: 57e4ac91fc62d75d84b5a03827a19ceb4094ecd9
>
>change-id: 20260928-section_has_mem_map-6205dc90a09f
>
>--
>
>Cheers,
>
>David
>
>
>

--- Thanks!
"I'm not a very positive person" - Linus torvalds