From: Bart Van Assche <bvanassche@acm.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
linux-kernel@vger.kernel.org, Marco Elver <elver@google.com>,
"Paul E . McKenney" <paulmck@kernel.org>,
Bart Van Assche <bvanassche@acm.org>,
Jonathan Corbet <corbet@lwn.net>,
Nathan Chancellor <nathan@kernel.org>
Subject: [PATCH 12/14] lockdep: Stop lockdep_assert_held*() from assuming lock ownership
Date: Mon, 2 Nov 2026 13:34:42 -0800 [thread overview]
Message-ID: <f470c5f2c98e89bd97c8e0b6b7befcfcfd3b00c1.1793654853.git.bvanassche@acm.org> (raw)
In-Reply-To: <cover.1793654853.git.bvanassche@acm.org>
Since commit 7c451541743c ("lockdep: Annotate lockdep assertions for
context analysis"), lockdep_assert_held(), lockdep_assert_held_write()
and lockdep_assert_held_read() instruct Clang's context analysis to
assume that a lock is held. This has the following disadvantages:
- lockdep_assert_held*() silences context analysis warnings in functions
that lack a __must_hold() or __must_hold_shared() annotation. Hence,
the compiler neither reports the missing function annotation nor
checks at compile time whether callers hold the lock.
- lockdep_assert_held() makes context analysis assume exclusive lock
ownership, even if a reader-writer lock is held in shared mode.
- lockdep_assert_held*() can only be used with lock types that are
defined with context_lock_struct().
Hence, remove the context assumptions from lockdep_assert_held*() for
both CONFIG_LOCKDEP and !CONFIG_LOCKDEP builds. Code that needs to
inform context analysis that a lock is held should use
lockdep_assume_ctx_held() or lockdep_assume_shared_ctx_held() instead.
Mention this in the kernel-doc comments of these macros.
Convert the __assume_ctx_lock() calls in kernel/locking/rtmutex.c into
lockdep_assume_ctx_held() calls such that the lock ownership assumptions
are verified at runtime. Remove the lockdep_assert_held(&lock->wait_lock)
call from __rt_mutex_slowlock() because lockdep_assume_ctx_held() now
performs the same runtime check.
Update Documentation/dev-tools/context-analysis.rst accordingly.
Cc: Marco Elver <elver@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
Documentation/dev-tools/context-analysis.rst | 18 ++++++++++++------
include/linux/lockdep.h | 18 ++++++++++++------
kernel/locking/rtmutex.c | 7 +++----
3 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/Documentation/dev-tools/context-analysis.rst b/Documentation/dev-tools/context-analysis.rst
index 8e71e1e75b5b..88b4ed6a182f 100644
--- a/Documentation/dev-tools/context-analysis.rst
+++ b/Documentation/dev-tools/context-analysis.rst
@@ -111,12 +111,18 @@ checking): either with a ``context_unsafe(var = init)`` expression, or by
marking small initialization functions with the ``__context_unsafe(init)``
attribute.
-Lockdep assertions, such as `lockdep_assert_held()`, inform the compiler's
-context analysis that the associated synchronization primitive is held after
-the assertion. This avoids false positives in complex control-flow scenarios
-and encourages the use of Lockdep where static analysis is limited. For
-example, this is useful when a function doesn't *always* require a lock, making
-`__must_hold()` inappropriate.
+`lockdep_assume_ctx_held()` and `lockdep_assume_shared_ctx_held()` inform the
+compiler's context analysis that the associated synchronization primitive is
+held and verify this at runtime via Lockdep. This avoids false positives in
+complex control-flow scenarios while still checking lock ownership with Lockdep
+where static analysis is limited. For example, this is useful when a function
+doesn't *always* require a lock, making `__must_hold()` inappropriate.
+
+Lockdep assertions, such as `lockdep_assert_held()`, only perform a runtime
+check and do not inform the compiler's context analysis that a lock is held.
+For context locks that are not tracked by Lockdep, e.g. bit spinlocks, use
+`__assume_ctx_lock()` or `__assume_shared_ctx_lock()` instead. These only
+inform the compiler's context analysis and do not perform a runtime check.
Keywords
~~~~~~~~
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index f774b22a35c5..ac2f1d2997a1 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -285,16 +285,16 @@ extern u32 lock_sequence(struct lockdep_map *lock);
do { WARN_ON_ONCE(debug_locks && !(cond)); } while (0)
#define lockdep_assert_held(l) \
- do { lockdep_assert(lockdep_is_held(l) != LOCK_STATE_NOT_HELD); __assume_ctx_lock(l); } while (0)
+ lockdep_assert(lockdep_is_held(l) != LOCK_STATE_NOT_HELD)
#define lockdep_assert_not_held(l) \
lockdep_assert(lockdep_is_held(l) != LOCK_STATE_HELD)
#define lockdep_assert_held_write(l) \
- do { lockdep_assert(lockdep_is_held_type(l, 0)); __assume_ctx_lock(l); } while (0)
+ lockdep_assert(lockdep_is_held_type(l, 0))
#define lockdep_assert_held_read(l) \
- do { lockdep_assert(lockdep_is_held_type(l, 1)); __assume_shared_ctx_lock(l); } while (0)
+ lockdep_assert(lockdep_is_held_type(l, 1))
#define lockdep_assert_held_once(l) \
lockdep_assert_once(lockdep_is_held(l) != LOCK_STATE_NOT_HELD)
@@ -392,10 +392,10 @@ extern int lockdep_is_held(const void *);
#define lockdep_assert(c) do { } while (0)
#define lockdep_assert_once(c) do { } while (0)
-#define lockdep_assert_held(l) __assume_ctx_lock(l)
+#define lockdep_assert_held(l) do { (void)(l); } while (0)
#define lockdep_assert_not_held(l) do { (void)(l); } while (0)
-#define lockdep_assert_held_write(l) __assume_ctx_lock(l)
-#define lockdep_assert_held_read(l) __assume_shared_ctx_lock(l)
+#define lockdep_assert_held_write(l) do { (void)(l); } while (0)
+#define lockdep_assert_held_read(l) do { (void)(l); } while (0)
#define lockdep_assert_held_once(l) do { (void)(l); } while (0)
#define lockdep_assert_none_held_once() do { } while (0)
@@ -436,6 +436,9 @@ extern int lockdep_is_held(const void *);
* has a dep_map member. For context locks that are not tracked by lockdep,
* e.g. bit spinlocks and the RCU context tokens, use
* __assume_ctx_lock() instead.
+ *
+ * Note: lockdep_assert_held() does not inform the compiler's context
+ * analysis that a lock is held. Use this macro if that is needed.
*/
#define lockdep_assume_ctx_held(var) \
_lockdep_assume_ctx_held(var, __UNIQUE_ID(ctx_lock))
@@ -467,6 +470,9 @@ extern int lockdep_is_held(const void *);
* @var must point at a lock object that is tracked by lockdep, i.e. that
* has a dep_map member. For context locks that are not tracked by lockdep,
* e.g. the RCU context tokens, use __assume_shared_ctx_lock() instead.
+ *
+ * Note: lockdep_assert_held_read() does not inform the compiler's context
+ * analysis that a lock is held. Use this macro if that is needed.
*/
#define lockdep_assume_shared_ctx_held(var) \
_lockdep_assume_shared_ctx_held(var, __UNIQUE_ID(ctx_lock))
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 5a9534c715b8..424cd38a72d2 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1259,7 +1259,7 @@ static int __sched task_blocks_on_rt_mutex(struct rt_mutex_base *lock,
/* Check whether the waiter should back out immediately */
rtm = container_of(lock, struct rt_mutex, rtmutex);
- __assume_ctx_lock(&rtm->rtmutex.wait_lock);
+ lockdep_assume_ctx_held(&rtm->rtmutex.wait_lock);
res = __ww_mutex_add_waiter(waiter, rtm, ww_ctx, wake_q);
if (res) {
raw_spin_lock(&task->pi_lock);
@@ -1634,7 +1634,7 @@ static int __sched rt_mutex_slowlock_block(struct rt_mutex_base *lock,
struct task_struct *owner;
int ret = 0;
- __assume_ctx_lock(&rtm->rtmutex.wait_lock);
+ lockdep_assume_ctx_held(&rtm->rtmutex.wait_lock);
lockevent_inc(rtmutex_slow_block);
for (;;) {
@@ -1724,8 +1724,7 @@ static int __sched __rt_mutex_slowlock(struct rt_mutex_base *lock,
struct ww_mutex *ww = ww_container_of(rtm);
int ret;
- __assume_ctx_lock(&rtm->rtmutex.wait_lock);
- lockdep_assert_held(&lock->wait_lock);
+ lockdep_assume_ctx_held(&rtm->rtmutex.wait_lock);
lockevent_inc(rtmutex_slowlock);
/* Try to acquire the lock again: */
next prev parent reply other threads:[~2026-11-02 21:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 21:34 [PATCH 00/14] " Bart Van Assche
2026-11-02 21:34 ` [PATCH 01/14] bit_spinlock: Fix the __bitlock() definition Bart Van Assche
2026-11-02 21:34 ` [PATCH 02/14] cleanup: Disable context analysis for __free() helpers Bart Van Assche
2026-11-02 21:34 ` [PATCH 03/14] tracing: Disable branch profiling for COMPILE_TEST builds Bart Van Assche
2026-11-02 21:34 ` [PATCH 04/14] srcu: Remove check from srcu_dereference_check() Bart Van Assche
2026-11-02 21:34 ` [PATCH 05/14] futex: Annotate __attach_to_pi_owner() and fixup_pi_*owner() Bart Van Assche
2026-11-02 21:34 ` [PATCH 06/14] locking/rwsem: Annotate rwsem internal functions with __must_hold() Bart Van Assche
2026-11-02 21:34 ` [PATCH 07/14] nvme-fabrics: Annotate nvmf_lookup_transport() with __must_hold_shared() Bart Van Assche
2026-11-02 21:34 ` [PATCH 08/14] lockdep: Introduce lockdep_assume_ctx_held() Bart Van Assche
2026-11-02 21:34 ` [PATCH 09/14] kfence: Use lockdep_assume_ctx_held() in kfence_report_error() Bart Van Assche
2026-11-02 21:34 ` [PATCH 10/14] Bluetooth: Add lock context annotations for connection aliases Bart Van Assche
2026-11-02 21:34 ` [PATCH 11/14] futex: Verify exit_mutex ownership in futex_exit_recursive() Bart Van Assche
2026-11-02 21:34 ` Bart Van Assche [this message]
2026-11-02 21:34 ` [PATCH 13/14] compiler-context-analysis: Split the RCU assertion tests Bart Van Assche
2026-11-02 21:34 ` [PATCH 14/14] rcu: Introduce lockdep_assume_in_rcu_*() Bart Van Assche
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=f470c5f2c98e89bd97c8e0b6b7befcfcfd3b00c1.1793654853.git.bvanassche@acm.org \
--to=bvanassche@acm.org \
--cc=boqun@kernel.org \
--cc=corbet@lwn.net \
--cc=elver@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--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
all inboxes | Powered by JetHome®