linux-kernel - Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

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: <41874647-a464-4884-9a39-544723d3e6b6@arm.com>
Date: Thu, 22 Jan 2026 13:47:16 +0000
From: Ryan Roberts <ryan.roberts@....com>
To: Yeoreum Yun <yeoreum.yun@....com>, Yang Shi <yang@...amperecomputing.com>
Cc: Will Deacon <will@...nel.org>, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
 catalin.marinas@....com, akpm@...ux-oundation.org, david@...nel.org,
 kevin.brodsky@....com, quic_zhenhuah@...cinc.com, dev.jain@....com,
 chaitanyas.prakash@....com, bigeasy@...utronix.de, clrkwllms@...nel.org,
 rostedt@...dmis.org, lorenzo.stoakes@...cle.com, ardb@...nel.org,
 jackmanb@...gle.com, vbabka@...e.cz, mhocko@...e.com
Subject: Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting
 the linear mapping

>>> I'm inclined to leave this as is for now.
>>
>> I agree. I don't think this would be a real problem.
>>
>> Thanks,
>> Yang
> 
> Although partially using GFP_ATOMIC might not be an issue given that
> there is no contention at the moment,
> technically using a memory allocation API inside stop_machine() is problematic
> for PREEMPT_RT, and the relevant page tables should be pre-allocated.
> 
> That said, taking a step back (I’m not sure why I was being so stubborn about this),
> since the kernel_alias area is mapped using block mappings,
> a simple calculation based on your dm_meminfo patch should be sufficient to
> determine the number of page tables that need to be pre-allocated for
> splitting the linear mapping, without having to walk the page tables again.
> 
> So, after your dm_meminfo patch, I plan to respin this patch based on that.
> 
> Am I missing anything?

Yeoreum and I had an offline chat about all this and I just want to spell out
the conclusion for everybody;

We believe it's impossible for the secondary CPUs to have any scheduled work
during this window, and therefore it's impossible for the split race to occur,
and it's impossible for there to be any contention on the page allocator lock.
All of which means that in practice, there are no bugs here and the code is safe
as is, even for PREEMPT_RT.

That said, allocating memory inside of stop_machine() is a bad smell, so Yeoreum
will rectify this down the track; it's not urgent though.

Thanks,
Ryan