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

[Vishal Moola]

On Thu, May 28, 2026 at 10:05:22AM +0200, Kevin Brodsky wrote:
> On 27/05/2026 11:30, Vishal Moola wrote:
> > On Wed, May 27, 2026 at 09:35:50AM +0200, Kevin Brodsky wrote:
> >> On 26/05/2026 17:07, Will Deacon wrote:
> >>> On Tue, May 26, 2026 at 01:54:00PM +0200, Kevin Brodsky wrote:
> >>>> On 22/05/2026 11:36, Vishal Moola wrote:
> >>>>>> 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)))
> >>>>> This should work.
> >>>>>
> >>>>>> +		pagetable_dtor(page_ptdesc(page));
> >>>>>> +
> >>>>>>  	free_hotplug_page_range(page, PAGE_SIZE, NULL);
> >>>>> In the case we presumably have a page table page (ptdesc) at this
> >>>>> point, we should really be freeing it with pagetable_free() as well.
> >>>> Agreed, I think this is the right thing to do, something like:
> >>>>
> >>>> if (folio_test_pgtable(page_folio(page)))
> >>>> pagetable_dtor_free(page_ptdesc(page)); else
> >>>> free_hotplug_page_range(page, PAGE_SIZE, NULL);
> >>>>
> >>>>
> >>>> Strangely enough x86 calls pagetable_free() in both cases.
> >>>>
> >>>> My series protecting page tables with pkeys has a patch [1] to get
> >>>> vmemmap to allocate page tables with pagetable_alloc(). The diff above
> >>>> will require pagetable_*_ctor() to be called as well, but I think that's
> >>>> the right thing to do anyway. That could be posted as a separate series,
> >>>> but I'm hesitant due to the lack of NUMA awareness in pagetable_alloc().
> >>> I agree that calling the ctor()/dtor() functions consistently is the
> >>> cleanest approach and that will need something like your patch to call
> >>> the constructor from vmemmap_alloc_block_zero(). Trying to elide these
> >>> calls for the page-table pages used to map the altmap just feels odd to
> >>> me, as there isn't anything particularly special about them afaik.
> >> I don't think they're really special either, most likely they just got
> >> missed/ignored for the purpose of ctor/dtor like many other kernel page
> >> tables (until recently).
> >>
> >> I'll prepare a series refactoring that code then - that will also
> >> require changing most arch implementations of vmemmap_free() to call
> >> pagetable_dtor_free().
> > Take a look at Matthew's series[1]. I think thats the ideal approach for
> > page table accounting. He hasn't had time to iterate on it though. I
> > doubt he'd mind if someone picked it up.
> 
> I recall this series. Are you suggesting that we would no longer need to
> call the ctor/dtor for kernel page tables with this approach? That
> leaves us with the weird case of ptdesc_set_kernel(), which is called
> from *_alloc_one() while ptdesc_clear_kernel() is called from
> pagetable_free(), but that's only an optimisation so we can probably
> live with it.

Pretty much. The ctor/dtor do things that every single page table should
be doing, so it makes sense to move them to the allocation/free sites
instead.

Kernel pagetables are a subset of ptdescs, so keeping those where they
are makes sense IMO.

> If we go down this route, I would suggest we inline what's left of the
> ctor/dtor, i.e. ptlock, in {pte,pmd}_alloc_one() and {pte,pmd}_free().
> This way it is clear that everything applicable to all page tables
> (kernel+user) should go directly into pagetable_{alloc,free}.
> 
> Happy to post something along those lines (patch 2/3 of Matthew's series
> + removing ctor/dtor completely) if that sounds sensible.

Sounds good to me :)