Re: [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