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

Message-ID: <CAADnVQLpSkaB7WtZDPiJ6qRBUjLE4tkwGo0i6Rqoko1aeLML4Q@mail.gmail.com>
Date: Mon, 31 Mar 2025 17:57:50 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Vlastimil Babka <vbabka@...e.cz>, Sebastian Sewior <bigeasy@...utronix.de>, 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, Mar 31, 2025 at 8:35 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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".

Here is the patch that goes back to that approach:

https://lore.kernel.org/bpf/20250401005134.14433-1-alexei.starovoitov@gmail.com/

btw the compiler error when local_lock_t (instead of
local_trylock_t) is passed into local_trylock_irqsave()
is imo quite readable:

../mm/memcontrol.c: In function ‘consume_stock’:
../include/linux/local_lock_internal.h:136:20: error: assignment to
‘local_trylock_t *’ from incompatible pointer type ‘local_lock_t *’
[-Werror=incompatible-pointer-types]
  136 |                 tl = this_cpu_ptr(lock);                        \
      |                    ^
../include/linux/local_lock.h:76:9: note: in expansion of macro
‘__local_trylock_irqsave’
   76 |         __local_trylock_irqsave(lock, flags)
      |         ^~~~~~~~~~~~~~~~~~~~~~~
../mm/memcontrol.c:1790:19: note: in expansion of macro ‘local_trylock_irqsave’
 1790 |         else if (!local_trylock_irqsave(&memcg_stock.stock_lock, flags))
      |                   ^~~~~~~~~~~~~~~~~~~~~