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: <DEYP7JSVTB9D.3EFN2KEHH3O79@google.com>
Date: Mon, 15 Dec 2025 09:55:26 +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 Mon Dec 15, 2025 at 9:34 AM UTC, Yeoreum Yun wrote:
> 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.

Hmm, I don't think "this code might be broken so let's cage it behind a
conditional" is a good strategy.

1. It bloats the codebase.

2. It's confusing to readers, now you have to try an understand why this
   conditional is here, which is a doomed effort. This could be
   mitigated with comments but, see point 1.

3. It expands the testing matrix. So now we have code that we aren't
   really sure is correct, AND it gets less test coverage.

Overall I am feeling a bit uncomfortable about this use of _nolock, but
I am also feeling pretty ignorant about PREEMPT_RT and also about this
arm64 code, so I am hesitant to suggest alternatives, I hope someone
else can offer some input here...