linux-kernel - Re: [PATCH 2/2] arm64: mmu: use pagetable_alloc_nolock() while stop

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

Message-ID: <aUPyllWslvMakLMx@e129823.arm.com>
Date: Thu, 18 Dec 2025 12:24:54 +0000
From: Yeoreum Yun <yeoreum.yun@....com>
To: Michal Hocko <mhocko@...e.com>
Cc: Ryan Roberts <ryan.roberts@....com>, akpm@...ux-foundation.org,
	david@...nel.org, lorenzo.stoakes@...cle.com,
	Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org,
	surenb@...gle.com, ast@...nel.org, daniel@...earbox.net,
	andrii@...nel.org, martin.lau@...ux.dev, eddyz87@...il.com,
	song@...nel.org, yonghong.song@...ux.dev, john.fastabend@...il.com,
	kpsingh@...nel.org, sdf@...ichev.me, haoluo@...gle.com,
	jolsa@...nel.org, jackmanb@...gle.com, hannes@...xchg.org,
	ziy@...dia.com, bigeasy@...utronix.de, clrkwllms@...nel.org,
	rostedt@...dmis.org, catalin.marinas@....com, will@...nel.org,
	kevin.brodsky@....com, dev.jain@....com,
	yang@...amperecomputing.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
	linux-rt-devel@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/2] arm64: mmu: use pagetable_alloc_nolock() while
 stop_machine()

> On Thu 18-12-25 12:02:14, Ryan Roberts wrote:
> > On 18/12/2025 09:36, Yeoreum Yun wrote:
> > > Hi,
> > >> On Fri 12-12-25 16:18:32, Yeoreum Yun wrote:
> > >>> linear_map_split_to_ptes() and __kpti_install_ng_mappings()
> > >>> are called as callback of stop_machine().
> > >>> That means these functions context are preemption disabled.
> > >>>
> > >>> Unfortunately, under PREEMPT_RT, the pagetable_alloc() or
> > >>> __get_free_pages() couldn't be called in this context
> > >>> since spin lock that becomes sleepable on RT,
> > >>> potentially causing a sleep during page allocation.
> > >>>
> > >>> To address this, pagetable_alloc_nolock().
> > >>
> > >> As you cannot tolerate allocation failure and this is pretty much
> > >> permanent allocation (AFAIU) why don't you use a static allocation?
> > >
> > > Because of when bbl2_noabort is supported, that pages doesn't need to.
> > > If static alloc, that would be a waste in the system where bbl2_noabort
> > > is supported.
> > >
> > > When I tested, these extra pages are more than 40 in my FVP.
> > > So, it would be better dynamic allocation and I think since it's quite a
> > > early time, it's probably not failed that's why former code runs as it
> > > is.
> >
> > The required allocation size is also a function of the size of the installed RAM
> > so a static worst case allocation would consume all the RAM on small systems.
>
> Understood. But is it possible to pre-allocate early on so that the
> allocation itself doesn't have to happen from a constrained context.

That's the same suggestion from Ryan
(https://lore.kernel.org/all/100cc8da-b826-4fc2-a624-746bf6fb049d@arm.com/)

And here is the v2 which have accepted his suggestion :)
(But soon respin):
https://lore.kernel.org/all/20251217182007.2345700-1-yeoreum.yun@arm.com/

Thanks ;)

--
Sincerely,
Yeoreum Yun