linux-kernel - Re: [PATCH 7/7] mm: make PT_RECLAIM depend on MMU_GATHER_RCU_TABLE

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: <9386032c-9840-49da-83f9-74b112f3e752@kernel.org>
Date: Wed, 19 Nov 2025 11:19:51 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Qi Zheng <qi.zheng@...ux.dev>, will@...nel.org, aneesh.kumar@...nel.org,
 npiggin@...il.com, peterz@...radead.org, dev.jain@....com,
 akpm@...ux-foundation.org, ioworker0@...il.com
Cc: linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, linux-alpha@...r.kernel.org,
 linux-snps-arc@...ts.infradead.org, loongarch@...ts.linux.dev,
 linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
 linux-um@...ts.infradead.org, Qi Zheng <zhengqi.arch@...edance.com>
Subject: Re: [PATCH 7/7] mm: make PT_RECLAIM depend on
 MMU_GATHER_RCU_TABLE_FREE && 64BIT

On 18.11.25 13:02, Qi Zheng wrote:
> 
> 
> On 11/18/25 12:57 AM, David Hildenbrand (Red Hat) wrote:
>> On 14.11.25 12:11, Qi Zheng wrote:
>>> From: Qi Zheng <zhengqi.arch@...edance.com>
>>
>> Subject: s/&&/&/
> 
> will do.
> 
>>
>>>
>>> Make PT_RECLAIM depend on MMU_GATHER_RCU_TABLE_FREE so that PT_RECLAIM
>>> can
>>> be enabled by default on all architectures that support
>>> MMU_GATHER_RCU_TABLE_FREE.
>>>
>>> Considering that a large number of PTE page table pages (such as 100GB+)
>>> can only be caused on a 64-bit system, let PT_RECLAIM also depend on
>>> 64BIT.
>>>
>>> Signed-off-by: Qi Zheng <zhengqi.arch@...edance.com>
>>> ---
>>>    arch/x86/Kconfig | 1 -
>>>    mm/Kconfig       | 6 +-----
>>>    2 files changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>>> index eac2e86056902..96bff81fd4787 100644
>>> --- a/arch/x86/Kconfig
>>> +++ b/arch/x86/Kconfig
>>> @@ -330,7 +330,6 @@ config X86
>>>        select FUNCTION_ALIGNMENT_4B
>>>        imply IMA_SECURE_AND_OR_TRUSTED_BOOT    if EFI
>>>        select HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
>>> -    select ARCH_SUPPORTS_PT_RECLAIM        if X86_64
>>>        select ARCH_SUPPORTS_SCHED_SMT        if SMP
>>>        select SCHED_SMT            if SMP
>>>        select ARCH_SUPPORTS_SCHED_CLUSTER    if SMP
>>> diff --git a/mm/Kconfig b/mm/Kconfig
>>> index a5a90b169435d..e795fbd69e50c 100644
>>> --- a/mm/Kconfig
>>> +++ b/mm/Kconfig
>>> @@ -1440,14 +1440,10 @@ config ARCH_HAS_USER_SHADOW_STACK
>>>          The architecture has hardware support for userspace shadow call
>>>              stacks (eg, x86 CET, arm64 GCS or RISC-V Zicfiss).
>>> -config ARCH_SUPPORTS_PT_RECLAIM
>>> -    def_bool n
>>> -
>>>    config PT_RECLAIM
>>>        bool "reclaim empty user page table pages"
>>>        default y
>>> -    depends on ARCH_SUPPORTS_PT_RECLAIM && MMU && SMP
>>> -    select MMU_GATHER_RCU_TABLE_FREE
>>> +    depends on MMU_GATHER_RCU_TABLE_FREE && MMU && SMP && 64BIT
>>
>> Who would we have MMU_GATHER_RCU_TABLE_FREE without MMU? (can we drop
>> the MMU part)
> 
> OK.
> 
>>
>> Why do we care about SMP in the first place? (can we frop SMP)
> 
> OK.
> 
>>
>> But I also wonder why we need "MMU_GATHER_RCU_TABLE_FREE && 64BIT":
>>
>> Would it be harmful on 32bit (sure, we might not reclaim as much, but
>> still there is memory to be reclaimed?)?
> 
> This is also fine on 32bit, but the benefits are not significant, So I
> chose to enable it only on 64-bit.

Right. Address space is smaller, but also memory is smaller. Not that I 
think we strictly *must* to support 32bit, I merely wonder why we 
wouldn't just enable it here.

OTOH, if there is a good reason we cannot enable it, we can definitely 
just keep it 64bit only.

> 
> I actually tried enabling MMU_GATHER_RCU_TABLE_FREE on all
> architectures, and apart from sparc32 being a bit troublesome (because
> it uses mm->page_table_lock for synchronization within
> __pte_free_tlb()), the modifications were relatively simple.
> 
>>
>> If all 64BIT support MMU_GATHER_RCU_TABLE_FREE (as you previously
>> state), why can't we only check for 64BIT?
> 
> OK, will do.

This was also more of a question for discussion:

Would it make sense to have

config PT_RECLAIM
	def_bool y
	depends on MMU_GATHER_RCU_TABLE_FREE

(a) Would we want to make it configurable (why?)
(b) Do we really care about SMP (why?)
(c) Do we want to limit to 64bit (why?)
(d) Do we really need the MMU check in addition to
     MMU_GATHER_RCU_TABLE_FREE


-- 
Cheers

David