linux-kernel - Re: [RFC PATCH] local_lock: Add local_lock access for a CPU-local pointer

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: <393a4c7f-c48f-4da1-a059-4c10f4094386@redhat.com>
Date: Fri, 18 Apr 2025 22:52:29 -0400
From: Waiman Long <llong@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 linux-kernel@...r.kernel.org
Cc: Boqun Feng <boqun.feng@...il.com>, Ingo Molnar <mingo@...hat.com>,
 Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>,
 Will Deacon <will@...nel.org>
Subject: Re: [RFC PATCH] local_lock: Add local_lock access for a CPU-local
 pointer

On 4/17/25 12:00 PM, Sebastian Andrzej Siewior wrote:
> For the most part the local_lock API expects __percpu pointer to operate
> on. So we have for instance
> 	local_lock(var.lock)
>
> and local_lock() will invoke this_cpu_ptr(var.lock) and do the actual
> locking on the resulting pointer. Good.
>
> There is one exception to this, that is local_lock_init(), which expects
> a CPU local (instead a __percpu) pointer. This is used with dynamic
> per-CPU memory allocation. You wouldn't have guessed that based on
> function naming but it is kind of obvious if you think about it. The two
> users, that use it, pass the __percpu pointer to the locking function so
> everything works as expected.
>
> Now I got to the case where a __percpu variable is made CPU-local and
> this pointer is passed to queue_work(). This is fine but the kworker
> operates on a CPU-local pointer and now I need local_lock()
> without the this_cpu_ptr() in it.
> Adding a _local to the function name would be a bit too local. I added
> _this instead but don't like it very much. Anyone with a better naming?

The "this" suffix looks a bit weird. Since you had introduced 
localtry_lock before, maybe you can follow a similar scheme like 
localcpu_lock.

My 2 cents.

Cheers,
Longman