Re: [PATCH v2 10/13] mm/sparse: remove SECTION_MARKED_PRESENT

Re: [PATCH v2 10/13] mm/sparse: remove SECTION_MARKED_PRESENT

[Dave Young]

Cced kexec list.

On Mon, Sep 28, 2026 at 09:28:08AM +0200, David Hildenbrand (Arm) wrote:
> On 9/27/26 21:20, David Carlier wrote:
> > On Mon, Sep 21, 2026 at 09:59:02PM +0200, David Hildenbrand (Arm) wrote:
> >>  enum {
> >> -	SECTION_MARKED_PRESENT_BIT,
> >>  	SECTION_HAS_MEM_MAP_BIT,
> >>  	SECTION_IS_ONLINE_BIT,
> >>  	SECTION_IS_EARLY_BIT,
> > 
> > Hi David,
> 
> Hi!
> 
> > 
> > It seems dropping SECTION_MARKED_PRESENT_BIT shifts the other section flags down
> > one bit. crash hardcodes SECTION_HAS_MEM_MAP as (1UL << 1) in
> > pfn_to_map(), so it now tests SECTION_IS_ONLINE: offline and
> > ZONE_DEVICE sections no longer resolve to a struct page. makedumpfile
> > only checks bit 0 and is fine.
> 
> Thanks. To be expected when relying on kernel internals.
> 
> Which makes me wonder why makedumpfile
> (https://github.com/makedumpfile/makedumpfile) not require any such information.
> 
> > 
> > Keep bit 0 reserved, or export the bits via vmcoreinfo?
> We could export it, or crash can simply detect the change based on the kernel
> version. I remember the latter was done in makedumpfile in the past (although we
> export it).
> 
> I can send a separate patch to export it.

Thanks David.   Checking kernel internals via kernel version is not a good idea
due to the downstream kernels.

> 
> -- 
> Cheers,
> 
> David

Re: [PATCH v2 10/13] mm/sparse: remove SECTION_MARKED_PRESENT

[David Hildenbrand (Arm)]

On 9/28/26 10:01, Dave Young wrote:
> Cced kexec list.
> 
> On Mon, Sep 28, 2026 at 09:28:08AM +0200, David Hildenbrand (Arm) wrote:
>> On 9/27/26 21:20, David Carlier wrote:
>>>
>>> Hi David,
>>
>> Hi!
>>
>>>
>>> It seems dropping SECTION_MARKED_PRESENT_BIT shifts the other section flags down
>>> one bit. crash hardcodes SECTION_HAS_MEM_MAP as (1UL << 1) in
>>> pfn_to_map(), so it now tests SECTION_IS_ONLINE: offline and
>>> ZONE_DEVICE sections no longer resolve to a struct page. makedumpfile
>>> only checks bit 0 and is fine.
>>
>> Thanks. To be expected when relying on kernel internals.
>>
>> Which makes me wonder why makedumpfile
>> (https://github.com/makedumpfile/makedumpfile) not require any such information.
>>
>>>
>>> Keep bit 0 reserved, or export the bits via vmcoreinfo?
>> We could export it, or crash can simply detect the change based on the kernel
>> version. I remember the latter was done in makedumpfile in the past (although we
>> export it).
>>
>> I can send a separate patch to export it.
> 
> Thanks David.   Checking kernel internals via kernel version is not a good idea
> due to the downstream kernels.

Patch at:

https://lore.kernel.org/r/20260928-section_has_mem_map-v1-1-4129f6ba2838@kernel.org

-- 
Cheers,

David