linux-kernel - Re: [PATCH] arm64: Enable vmalloc-huge with ptdump

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250611093337.GB10885@willie-the-truck>
Date: Wed, 11 Jun 2025 10:33:38 +0100
From: Will Deacon <will@...nel.org>
To: Dev Jain <dev.jain@....com>
Cc: Ryan Roberts <ryan.roberts@....com>, catalin.marinas@....com,
	anshuman.khandual@....com, quic_zhenhuah@...cinc.com,
	kevin.brodsky@....com, yangyicong@...ilicon.com, joey.gouly@....com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	david@...hat.com
Subject: Re: [PATCH] arm64: Enable vmalloc-huge with ptdump

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