Re: [PATCH v4] mm: fix accounting of memmap pages

[David Hildenbrand <david@redhat.com>]

On 07.08.25 20:35, Sumanth Korikkar wrote:
> For !CONFIG_SPARSEMEM_VMEMMAP, memmap page accounting is currently done
> upfront in sparse_buffer_init(). However, sparse_buffer_alloc() may
> return NULL in failure scenario.
> 
> Also, memmap pages may be allocated either from the memblock allocator
> during early boot or from the buddy allocator. When removed via
> arch_remove_memory(), accounting of memmap pages must reflect the
> original allocation source.
> 
> To ensure correctness:
> * Account memmap pages after successful allocation in sparse_init_nid()
>    and section_activate().
> * Account memmap pages in section_deactivate() based on allocation
>    source.
> 
> Cc: stable@vger.kernel.org
> Fixes: 15995a352474 ("mm: report per-page metadata information")
> Suggested-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
> ---
> v4:
> * Add fixes and suggested-by.
> 
> v3:
> * Account memmap pages for !CONFIG_SPARSEMEM_VMEMMAP and only when memmap
>    allocation succeeds. Thanks Wei Yang.
> 
> v2:
> * Account memmap pages for  !CONFIG_SPARSEMEM_VMEMMAP in
>    section_deactivate().  Thanks David.
> * https://lore.kernel.org/all/20250804151328.2326642-1-sumanthk@linux.ibm.com/
> 
> v1:
> * Account memmap pages for early sections.
> * https://lore.kernel.org/all/20250804084015.270570-1-sumanthk@linux.ibm.com/
> 
>   mm/sparse-vmemmap.c |  5 -----
>   mm/sparse.c         | 15 +++++++++------
>   2 files changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> index fd2ab5118e13..41aa0493eb03 100644
> --- a/mm/sparse-vmemmap.c
> +++ b/mm/sparse-vmemmap.c
> @@ -578,11 +578,6 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn,
>   	if (r < 0)
>   		return NULL;
>   
> -	if (system_state == SYSTEM_BOOTING)
> -		memmap_boot_pages_add(DIV_ROUND_UP(end - start, PAGE_SIZE));
> -	else
> -		memmap_pages_add(DIV_ROUND_UP(end - start, PAGE_SIZE));
> -
>   	return pfn_to_page(pfn);
>   }
>   
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 066cbf82acb8..24323122f6cb 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -454,9 +454,6 @@ static void __init sparse_buffer_init(unsigned long size, int nid)
>   	 */
>   	sparsemap_buf = memmap_alloc(size, section_map_size(), addr, nid, true);
>   	sparsemap_buf_end = sparsemap_buf + size;
> -#ifndef CONFIG_SPARSEMEM_VMEMMAP
> -	memmap_boot_pages_add(DIV_ROUND_UP(size, PAGE_SIZE));
> -#endif
>   }
>   
>   static void __init sparse_buffer_fini(void)
> @@ -567,6 +564,8 @@ static void __init sparse_init_nid(int nid, unsigned long pnum_begin,
>   				sparse_buffer_fini();
>   				goto failed;
>   			}
> +			memmap_boot_pages_add(DIV_ROUND_UP(PAGES_PER_SECTION * sizeof(struct page),
> +							   PAGE_SIZE));

IIRC, we can have partially populated boot sections, where only some 
subsections actually have a memmap ... so this calculation is possibly 
wrong in some cases.

-- 
Cheers,

David / dhildenb