linux-kernel - Re: [GIT PULL] Introduce try_alloc

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: <CAHk-=wj1jFH2Gc2Pq+-m_32BL9-CbdD7vReTJgd7Wbt2_EnH3Q@mail.gmail.com>
Date: Mon, 31 Mar 2025 08:35:05 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Sebastian Sewior <bigeasy@...utronix.de>, 
	Alexei Starovoitov <alexei.starovoitov@...il.com>, bpf <bpf@...r.kernel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, 
	Martin KaFai Lau <martin.lau@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Peter Zijlstra <peterz@...radead.org>, Steven Rostedt <rostedt@...dmis.org>, 
	Michal Hocko <mhocko@...e.com>, Shakeel Butt <shakeel.butt@...ux.dev>, linux-mm <linux-mm@...ck.org>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Introduce try_alloc_pages for 6.15

On Mon, 31 Mar 2025 at 02:59, Vlastimil Babka <vbabka@...e.cz> wrote:
>
> Yes I was going to point out that e.g. "nmisafe_local_lock_irqsave()" seems
> rather misleading to me as this operation is not a nmisafe one?

Yeah, it's not a great name either, IO admit.

> The following attempt [2] meant there would be only a new local_trylock_t
> type, but the existing locking operations would remain the same, relying on
> _Generic() parts inside them.

Hmm. I actually like that approach.

That avoids having the misleading operation naming. IOW, you'd not
have a "localtry" when it's not a trylock, and you'd not have
"nmisafe" when it's not an operation that is actually nmi-safe.

The downside of _Generic() is that it's a bit subtle and can hide the
actual operation, but I think that in this situation that's the whole
point.

So yes, I'd vote for the "let's just introduce the new type that has
the required 'acquired' field, and then use a _Generic() model to
automatically pick the right op".

                Linus