[PATCH] arm64: Enable vmalloc-huge with ptdump

[Will Deacon]

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.

Will