Re: [PATCH 09/12] mm/sparse: remove SECTION_MARKED_PRESENT

["David Hildenbrand (Arm)" <david@kernel.org>]

On 9/10/26 16:32, Lorenzo Stoakes (ARM) wrote:
> On Wed, Sep 09, 2026 at 03:33:02PM +0200, David Hildenbrand (Arm) wrote:
>> All present section iterators run before memory hotplug added any
>> further memory sections, Therefore, we can simply use the SECTION_IS_EARLY
>> flag by setting that flag earlier in sparse_prepare_early_sections().
> 
> Hmm? sparse_prepare_early_sections() doesn't seem to be a function that exists?
> 
> Do you mean sparse_sections_init()?

Rebase artifact, thanks! :)

> 
>>
>> Get rid of SECTION_MARKED_PRESENT entirely and rename
>> for_each_present_section_nr() to for_each_early_section_nr().
>>
>> Also update the gdb script to use the updated value for
>> SECTION_IS_EARLY.
> 
> The change seems fine.
> 
>>
>> No functional change intended.
>>
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> 
> With commit msg updated:
> 
> Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> 
> One small question type comment below.

Thanks!

[...]

>> +++ b/scripts/gdb/linux/mm.py
>> @@ -76,7 +76,7 @@ class x86_page_ops():
>>              self.SECTION_IS_EARLY = 1 << int(gdb.parse_and_eval('SECTION_IS_EARLY_BIT'))
>>          except:
>>              self.SECTION_HAS_MEM_MAP = 1 << 0
>> -            self.SECTION_IS_EARLY = 1 << 3
>> +            self.SECTION_IS_EARLY = 1 << 2
> 
> Seems a bit strage given the code is:
> 
>         try:
>             self.SECTION_HAS_MEM_MAP = 1 << int(gdb.parse_and_eval('SECTION_HAS_MEM_MAP_BIT'))
>             self.SECTION_IS_EARLY = 1 << int(gdb.parse_and_eval('SECTION_IS_EARLY_BIT'))
>         except:
>             self.SECTION_HAS_MEM_MAP = 1 << 0
>             self.SECTION_IS_EARLY = 1 << 2
> 
> Whereas other variables must be available with no try, e.g.:
> 
>         self.PAGE_OFFSET = int(gdb.parse_and_eval("page_offset_base"))
>         self.VMEMMAP_START = int(gdb.parse_and_eval("vmemmap_base"))
>         self.PHYS_BASE = int(gdb.parse_and_eval("(unsigned long) phys_base"))
> 
> etc.
> 
> Is there some weirdness with gdb? Or is it maybe because there are some configs
> without these symbols maybe?

TBH, I have absolutely no idea and I was asking myself the same thing (but
decided that I couldn't care less about a python gdb script).

This code was added in February:

commit 55f8b4518d14b7436f70defe27faba4eca0cd4e1
Author: Seongjun Hong <hsj0512@snu.ac.kr>
Date:   Mon Feb 2 12:42:41 2026 +0900

    scripts/gdb: implement x86_page_ops in mm.py

    Implement all member functions of x86_page_ops strictly following the
    logic of aarch64_page_ops.

    This includes full support for SPARSEMEM and standard page translation
    functions.

    This fixes compatibility with 'lx-' commands on x86_64, preventing
    AttributeErrors when using lx-pfn_to_page and others.

@Seongjun, why are these conditional and the others not? Trying to support older
kernels?


-- 
Cheers,

David