linux-kernel - Re: [PATCH v5 12/14] mm: add config option for clearing page-extents

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <9865895d-c9bf-42e2-b813-bdbd39ad3af1@redhat.com>
Date: Fri, 11 Jul 2025 21:26:22 +0200
From: David Hildenbrand <david@...hat.com>
To: Ankur Arora <ankur.a.arora@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org,
 akpm@...ux-foundation.org, bp@...en8.de, dave.hansen@...ux.intel.com,
 hpa@...or.com, mingo@...hat.com, mjguzik@...il.com, luto@...nel.org,
 peterz@...radead.org, acme@...nel.org, namhyung@...nel.org,
 tglx@...utronix.de, willy@...radead.org, raghavendra.kt@....com,
 boris.ostrovsky@...cle.com, konrad.wilk@...cle.com
Subject: Re: [PATCH v5 12/14] mm: add config option for clearing page-extents

On 11.07.25 19:32, Ankur Arora wrote:
> 
> David Hildenbrand <david@...hat.com> writes:
> 
>> On 10.07.25 02:59, Ankur Arora wrote:
>>> Add CONFIG_CLEAR_PAGE_EXTENT to allow clearing of page-extents
>>> where architecturally supported.
>>> This is only available with !CONFIG_HIGHMEM because the intent is to
>>> use architecture support to clear contiguous extents in a single
>>> operation (ex. via FEAT_MOPS on arm64, string instructions on x86)
>>> which excludes any possibility of interspersing kmap()/kunmap().
>>> Signed-off-by: Ankur Arora <ankur.a.arora@...cle.com>
>>> ---
>>
>> Staring at the next patch, I think this can easily be squashed into the next
>> patch where you add actual MM core support.
> 
> I wanted to do this in a separate patch to explicitly document what the
> responsibility of the interface provided by the architecture is.
> That said, the commit message didn't actually do a good job of doing
> that :D.
> 
> Copying the more detailed commit message from my reply to Andrew,
> one important part of the clear_pages() is that it be interruptible
> because clear_pages_resched() implicitly depends on it.
> 
>> This is only enabled with !CONFIG_HIGHMEM because the intent is
>> to use architecture support to clear contiguous extents in a
>> single interruptible operation (ex. via FEAT_MOPS on arm64,
>> string instructions on x86).
> 
>> Given that we might be zeroing the whole extent with a single
>> instruction, this excludes any possibility of constructing
>> intermediate HIGHMEM maps.
> 
> Do you think it is best documented in the next patch in a comment
> instead?

I would just add + document it as part of the next patch.

Looking at the bigger picture now, you introduce

	ARCH_HAS_CLEAR_PAGES

To say whether an architecture provides clear_pages().

Now we want to conditionally use that to optimize folio_zero_user().

Remind me, why do we want to glue this to THP / HUGETLBFS only? I would 
assume that the code footprint is rather small, and the systems out 
there that are compiled with ARCH_HAS_CLEAR_PAGES but without THP / 
HUGETLBFS are rather ... rare (mostly 32BIT x86 only).

-- 
Cheers,

David / dhildenb