Re: [PATCH 14/22] mm: set page table page type when allocated

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing PG_table page type initialization for custom allocators that bypass pagetable_alloc_noprof().
- [Medium] Bypassing pagetable_free() causes leaked PG_table state and permanent NR_PAGETABLE accounting leaks.
--

--- Patch [14]: [PATCH 14/22] mm: set page table page type when allocated ---
commit ec9e373da7e406797591704d23e05fdbf402dfe3
Author: Kevin Brodsky <kevin.brodsky@arm.com>

mm: set page table page type when allocated

This commit moves page table page type updates from the constructors and
destructors directly into pagetable_alloc_noprof() and __pagetable_free().
It leaves __pagetable_ctor() empty and removes it.

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

> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 361a0d7b74c51..94f0fb1c662ae 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
[ ... ]
> @@ -3799,19 +3801,9 @@ static inline bool ptlock_init(struct ptdesc *ptdesc) { return true; }
>  static inline void ptlock_free(struct ptdesc *ptdesc) {}
>  #endif /* defined(CONFIG_SPLIT_PTE_PTLOCKS) */
>  
> -static inline void __pagetable_ctor(struct ptdesc *ptdesc)
> -{
> -	struct folio *folio = ptdesc_folio(ptdesc);
> -
> -	__folio_set_pgtable(folio);
> -}
> -
>  static inline void pagetable_dtor(struct ptdesc *ptdesc)
>  {
> -	struct folio *folio = ptdesc_folio(ptdesc);
> -
>  	ptlock_free(ptdesc);
> -	__folio_clear_pgtable(folio);
>  }

[Severity: Medium]
Since __folio_clear_pgtable() was moved to __pagetable_free(), what happens to
architectures that bypass __pagetable_free() entirely?

For example, without CONFIG_MMU_GATHER_TABLE_FREE, tlb_remove_table() calls
pagetable_dtor() and frees the page directly via the batcher:

include/asm-generic/tlb.h:tlb_remove_table() {
    ...
	pagetable_dtor(ptdesc);
	tlb_remove_page(tlb, ptdesc_page(ptdesc));
}

Similarly, arm64 memory hot-remove frees pages directly:

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

Will this bypass cause a permanent leak in the NR_PAGETABLE counter and leave
the PG_table flag set on the page as it enters the buddy allocator?

>  static inline void pagetable_dtor_free(struct ptdesc *ptdesc)
> @@ -3825,7 +3817,6 @@ static inline bool pagetable_pte_ctor(struct mm_struct *mm,
>  {
>  	if (!mm_is_kernel(mm) && !ptlock_init(ptdesc))
>  		return false;
> -	__pagetable_ctor(ptdesc);
>  	return true;
>  }

[Severity: Medium]
Are there custom allocators that rely on pagetable_pte_ctor() to initialize
the page type?

For instance, on SPARC32, user PTE tables are allocated via a custom pool
using srmmu_get_nocache() which bypasses pagetable_alloc_noprof(). They
rely on pagetable_pte_ctor() to set the page type:

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

By removing __pagetable_ctor() here, it seems these pages will no longer
have the PG_table flag set. Is this the intended behavior?

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