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: <DEYOI8H2OESD.1H56D3H8HKILB@google.com>
Date: Mon, 15 Dec 2025 09:22:22 +0000
From: Brendan Jackman <jackmanb@...gle.com>
To: Yeoreum Yun <yeoreum.yun@....com>, 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()

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?