[PATCH] arm64: mm: call pagetable dtor when freeing hot-removed page tables
Will Deacon
will at kernel.org
Tue May 26 08:07:45 PDT 2026
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.
Will
More information about the linux-arm-kernel
mailing list