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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <3878b4ac-154d-42f1-98ef-d619a455ee07@arm.com>
Date: Wed, 11 Jun 2025 17:48:58 +0530
From: Dev Jain <dev.jain@....com>
To: Will Deacon <will@...nel.org>
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 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