[PATCH] arm64: Enable vmalloc-huge with ptdump

[Dev Jain]

On 11/06/25 3:03 pm, Will Deacon wrote:
> On Thu, Jun 05, 2025 at 01:46:01PM +0530, Dev Jain wrote:
>> On 05/06/25 10:18 am, Dev Jain wrote:
>>> On 30/05/25 7:06 pm, Will Deacon wrote:
>>>> On Fri, May 30, 2025 at 02:11:36PM +0100, Ryan Roberts wrote:
>>>>> On 30/05/2025 13:35, Will Deacon wrote:
>>>>>> I really don't think we should be adding unconditional
>>>>>> locking overhead
>>>>>> to core mm routines purely to facilitate a rarely used debug option.
>>>>>>
>>>>>> Instead, can we either adopt something like the RCU-like walk used by
>>>>>> fast GUP or stick the locking behind a static key that's only enabled
>>>>>> when a ptdump walk is in progress (a bit like how
>>>>>> hugetlb_vmemmap_optimize_folio() manipulates
>>>>>> hugetlb_optimize_vmemmap_key)?
>>>>> My sense is that the static key will be less effort and can be
>>>>> contained fully
>>>>> in arm64. I think we would need to enable the key around the call to
>>>>> ptdump_walk_pgd() in both ptdump_walk() and ptdump_check_wx().
>>>>> Then where Dev is
>>>>> currently taking the read lock, that would be contingent on the
>>>>> key being
>>>>> enabled and the unlock would be contingent on having taken the lock.
>>>>>
>>>>> Does that sound like an acceptable approach?
>>>> Yup, and I think you'll probably need something like a synchronize_rcu()
>>>> when flipping the key to deal with any pre-existing page-table freers.
>>> IIUC, you mean to say that we need to ensure any existing readers having
>>> a reference to the isolated table in pmd_free_pte_page and friend, have
>>> exited.
>>> But the problem is that we take an mmap_write_lock() around
>>> ptdump_walk_pgd() so
>>> this is a sleepable code path.
>> The mmap_write_lock around ptdump_walk_pgd() is definitely restrictive. I
>> think that
>>
>> was put because ptdump is rarely used, I think we could have done
>> RCU-freeing of pagetables to
>>
>> synchronize between ptdump and vmalloc pagetable lazy freeing/ hotunplug
>> pagetable freeing.
> The other idea was to use a static key like the HVO code does, which
> shouldn't place any RCU requirements on the debug walk.

Thanks for your suggestion. I shall look into this.

>
> Will