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

[Waiman Long <llong@redhat.com>]

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