Re: [PATCH] arm64: mm: call pagetable dtor when freeing hot-removed page tables
From: Kevin Brodsky
Date: Thu May 28 2026 - 04:14:21 EST
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.
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.
- Kevin