Re: [PATCH] arm64: mm: call pagetable dtor when freeing hot-removed page tables

[Will Deacon]

On Mon, Jun 01, 2026 at 09:22:25PM -0700, Andrew Morton wrote:
> On Fri, 22 May 2026 08:15:09 +0100 Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
> 
> > > > --- a/arch/arm64/mm/mmu.c
> > > > +++ b/arch/arm64/mm/mmu.c
> > > > @@ -1422,6 +1422,7 @@ static void free_hotplug_page_range(struct page *page, size_t size,
> > > >  
> > > >  static void free_hotplug_pgtable_page(struct page *page)
> > > >  {
> > > > +	pagetable_dtor(page_ptdesc(page));
> > > >  	free_hotplug_page_range(page, PAGE_SIZE, NULL);
> > > >  }
> > > 
> > > I'd of course prefer that arm maintainers handle this.  But
> > > 5e8eb9aeeda3 came via myself so convention kinda-dictates that I get to
> > > fix it.
> > 
> > That's fine but Sashiko has some points:
> > 
> > https://sashiko.dev/#/patchset/20260521032730.2104017-1-apopple@xxxxxxxxxx
> > 
> > The __remove_pgd_mapping() path is fine but we also have the
> > vmemmap_free() path where the constructor was never called.
> > 
> > We could pass around a bool dtor argument but I wonder whether we could
> > just check it's a pgtable page:
> > 
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 4c8959153ac4..9d42cbddce27 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1441,6 +1441,9 @@ static void free_hotplug_page_range(struct page *page, size_t size,
> >  
> >  static void free_hotplug_pgtable_page(struct page *page)
> >  {
> > +	if (folio_test_pgtable(page_folio(page)))
> > +		pagetable_dtor(page_ptdesc(page));
> > +
> >  	free_hotplug_page_range(page, PAGE_SIZE, NULL);
> >  }
> 
> This patch is still floating around in mm.git awaiting some
> finalization.  What to do?

>From what I can tell (assuming I've been following along correctly!):

1. This patch improves the situation, so makes sense in its own right
2. There is additional work to be more consistent with the constructors
   for page-table pages, which Kevin is going to look at but is probably
   a little more long-term.
3. I'm happy to take this via arm64 but also have no issues with you taking
   it via mm (so please shout if you want me to pick it up).

Will