Re: [PATCH 13/22] mm: account page table pages when allocated

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] NR_PAGETABLE statistic leak on architectures that do not define CONFIG_MMU_GATHER_TABLE_FREE.
- [Medium] Direct calls to pagetable_dtor() followed by generic page freeing functions bypass the NR_PAGETABLE decrement, causing stat leaks on ARM64 memory hot-remove.
- [Medium] SPARC32 SRMMU page tables completely lose NR_PAGETABLE accounting.
- [Medium] Memory hot-remove and vmemmap teardown on x86 will underflow the NR_PAGETABLE counter.
--

--- Patch [13]: [PATCH 13/22] mm: account page table pages when allocated ---
commit 5c303720c0cd77f50e7b180d025a9a9869aab6a2
Author: Kevin Brodsky <kevin.brodsky@arm.com>
mm: account page table pages when allocated

This commit moves memory accounting of pagetable pages from the ctor/dtor
functions to pagetable_alloc() and pagetable_free() in order to improve
accounting where ctor/dtor calls might be missing.

Link: https://lore.kernel.org/r/20251113140448.1814860-3-willy@infradead.org

> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b336eb32faa05..361a0d7b74c51 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3681,6 +3681,11 @@ static inline struct ptdesc *pagetable_alloc_noprof(gfp_t gfp, unsigned int orde
>  {
>  	struct page *page = alloc_pages_noprof(gfp | __GFP_COMP, order);
>  
> +	if (!page)
> +		return NULL;
> +
> +	lruvec_stat_add_folio(page_folio(page), NR_PAGETABLE);
> +
>  	return page_ptdesc(page);
>  }

[Severity: Medium]
For architectures or code paths that allocate page tables without using
pagetable_alloc_noprof(), will we now lose the NR_PAGETABLE accounting?

For example, on SPARC32, pte_alloc_one() in arch/sparc/mm/srmmu.c allocates
from a pre-allocated pool via srmmu_get_nocache() and previously relied on
pagetable_pte_ctor() to increment the stat:

arch/sparc/mm/srmmu.c:pte_alloc_one() {
    ...
	if (page_ref_inc_return(page) == 2 &&
		!pagetable_pte_ctor(mm, page_ptdesc(page))) {
    ...
}

Similarly, the freeing path mirrors this bypass, using srmmu_free_nocache()
instead of pagetable_free(). Does this change cause SPARC32 to completely
lose user PTE accounting?

> @@ -3689,6 +3694,8 @@ static inline void __pagetable_free(struct ptdesc *pt)
>  {
>  	struct page *page = ptdesc_page(pt);
>  
> +	lruvec_stat_sub_folio(page_folio(page), NR_PAGETABLE);
> +
>  	__free_pages(page, compound_order(page));
>  }

[Severity: Medium]
Will this cause an underflow on x86 during memory hot-remove?

In arch/x86/mm/init_64.c, free_pagetable() calls pagetable_free() (which
now decrements the stat) during hot-remove:

arch/x86/mm/init_64.c:free_pagetable() {
    ...
	if (PageReserved(page))
		free_reserved_page(page);
	else
		pagetable_free(page_ptdesc(page));
}

However, these kernel page tables were originally allocated during hot-add
with spp_getpage() or vmemmap_alloc_block_buf(). Both of these use base
allocators and bypass pagetable_alloc_noprof().

Because the stat is never incremented on allocation but is now decremented
on free, does this cause an underflow?

[ ... ]

> @@ -3797,7 +3804,6 @@ static inline void __pagetable_ctor(struct ptdesc *ptdesc)
>  	struct folio *folio = ptdesc_folio(ptdesc);
>  
>  	__folio_set_pgtable(folio);
> -	lruvec_stat_add_folio(folio, NR_PAGETABLE);
>  }
>  
>  static inline void pagetable_dtor(struct ptdesc *ptdesc)
> @@ -3806,7 +3812,6 @@ static inline void pagetable_dtor(struct ptdesc *ptdesc)
>  
>  	ptlock_free(ptdesc);
>  	__folio_clear_pgtable(folio);
> -	lruvec_stat_sub_folio(folio, NR_PAGETABLE);
>  }

[Severity: Medium]
Will this leak the NR_PAGETABLE counter on architectures that bypass
__pagetable_free() and only call pagetable_dtor()?

On architectures lacking CONFIG_MMU_GATHER_TABLE_FREE (like m68k or xtensa),
the fallback tlb_remove_table() implementation explicitly calls
pagetable_dtor() and then enqueues the page for generic batch freeing:

include/asm-generic/tlb.h:tlb_remove_table() {
	struct ptdesc *ptdesc = (struct ptdesc *)table;

	pagetable_dtor(ptdesc);
	tlb_remove_page(tlb, ptdesc_page(ptdesc));
}

Since the decrement was moved from pagetable_dtor() to __pagetable_free(),
which is bypassed here, will this leak the counter when userspace unmaps
memory?

A similar bypass appears to occur on ARM64 during memory hot-remove:

arch/arm64/mm/mmu.c:free_hotplug_pgtable_page() {
	pagetable_dtor(page_ptdesc(page));
	free_hotplug_page_range(page, PAGE_SIZE, NULL);
}

Since this directly calls pagetable_dtor() and skips __pagetable_free(),
will this also leave the stat un-decremented?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-remove_pgtable_cdtor-v1-0-44be8a7685d7@arm.com?part=13