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

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

Message-ID: <aT/WOAr4osoJWaMS@e129823.arm.com>
Date: Mon, 15 Dec 2025 09:34:48 +0000
From: Yeoreum Yun <yeoreum.yun@....com>
To: Brendan Jackman <jackmanb@...gle.com>
Cc: akpm@...ux-foundation.org, david@...nel.org, lorenzo.stoakes@...cle.com,
	Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org,
	surenb@...gle.com, mhocko@...e.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, hannes@...xchg.org,
	ziy@...dia.com, bigeasy@...utronix.de, clrkwllms@...nel.org,
	rostedt@...dmis.org, catalin.marinas@....com, will@...nel.org,
	ryan.roberts@....com, 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()

Hi Brendan,
> On Sun Dec 14, 2025 at 9:13 AM UTC, Yeoreum Yun wrote:
> >> I don't have the context on what this code is doing so take this with
> >> a grain of salt, but...
> >>
> >> The point of the _nolock alloc is to give the allocator an excuse to
> >> fail. Panicking on that failure doesn't seem like a great idea to me?
> >
> > I thought first whether it changes to "static" memory area to handle
> > this in PREEMPT_RT.
> > But since this function is called while smp_cpus_done().
> > So, I think it's fine since there wouldn't be a contention for
> > memory allocation in this phase.
>
> Then shouldn't it use _nolock unconditionally?

As you pointed out, I think it should be fine even in the !PREEMPT_RT case.
However, in case I missed something or if my understanding is incorrect,
I applied it only to the PREEMPT_RT case for now.

--
Sincerely,
Yeoreum Yun