From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: linux-kernel@vger.kernel.org
Cc: Boqun Feng <boqun.feng@gmail.com>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Waiman Long <longman@redhat.com>, Will Deacon <will@kernel.org>
Subject: [RFC PATCH] local_lock: Add local_lock access for a CPU-local pointer
Date: Thu, 17 Apr 2025 18:00:57 +0200 [thread overview]
Message-ID: <20250417160057.jFRLMwfF@linutronix.de> (raw)
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?
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
include/linux/local_lock.h | 6 ++++++
include/linux/local_lock_internal.h | 20 ++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/include/linux/local_lock.h b/include/linux/local_lock.h
index 1a0bc35839e36..5bce77200248b 100644
--- a/include/linux/local_lock.h
+++ b/include/linux/local_lock.h
@@ -138,6 +138,12 @@ DEFINE_LOCK_GUARD_1(local_lock_irqsave, local_lock_t __percpu,
#define local_unlock_nested_bh(_lock) \
__local_unlock_nested_bh(_lock)
+#define local_lock_nested_bh_this(_lock) \
+ __local_lock_nested_bh_this(_lock)
+
+#define local_unlock_nested_bh_this(_lock) \
+ __local_unlock_nested_bh_this(_lock)
+
DEFINE_GUARD(local_lock_nested_bh, local_lock_t __percpu*,
local_lock_nested_bh(_T),
local_unlock_nested_bh(_T))
diff --git a/include/linux/local_lock_internal.h b/include/linux/local_lock_internal.h
index 67bd13d142fac..84556b7d298f9 100644
--- a/include/linux/local_lock_internal.h
+++ b/include/linux/local_lock_internal.h
@@ -129,9 +129,18 @@ do { \
local_lock_acquire(this_cpu_ptr(lock)); \
} while (0)
+#define __local_lock_nested_bh_this(lock) \
+ do { \
+ lockdep_assert_in_softirq(); \
+ local_lock_acquire(lock); \
+ } while (0)
+
#define __local_unlock_nested_bh(lock) \
local_lock_release(this_cpu_ptr(lock))
+#define __local_unlock_nested_bh_this(lock) \
+ local_lock_release(lock)
+
/* localtry_lock_t variants */
#define __localtry_lock_init(lock) \
@@ -278,11 +287,22 @@ do { \
spin_lock(this_cpu_ptr(lock)); \
} while (0)
+#define __local_lock_nested_bh_this(lock) \
+do { \
+ lockdep_assert_in_softirq_func(); \
+ spin_lock(lock); \
+} while (0)
+
#define __local_unlock_nested_bh(lock) \
do { \
spin_unlock(this_cpu_ptr((lock))); \
} while (0)
+#define __local_unlock_nested_bh_this(lock) \
+do { \
+ spin_unlock(lock); \
+} while (0)
+
/* localtry_lock_t variants */
#define __localtry_lock_init(lock) __local_lock_init(lock)
--
2.49.0
next reply other threads:[~2025-04-17 16:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 16:00 Sebastian Andrzej Siewior [this message]
2025-04-19 2:52 ` [RFC PATCH] local_lock: Add local_lock access for a CPU-local pointer Waiman Long
2025-04-25 9:14 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250417160057.jFRLMwfF@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox