All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: intel-xe@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Matthew Auld" <matthew.auld@intel.com>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>, "Will Deacon" <will@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Waiman Long" <longman@redhat.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org
Subject: [RFC PATCH 1/2] kernel/locking/ww_mutex: Add per-lock lock-check helpers
Date: Thu, 20 Nov 2025 12:03:40 +0100	[thread overview]
Message-ID: <20251120110341.2425-2-thomas.hellstrom@linux.intel.com> (raw)
In-Reply-To: <20251120110341.2425-1-thomas.hellstrom@linux.intel.com>

Code using ww_mutexes typically by design have a number of
such mutexes sharing the same ww_class, and within a ww transaction
they are all lockdep annotated using a nest_lock which means
that multiple ww_mutexes of the same lockdep class may be locked at
the same time. That means that lock_is_held() returns true and
lockdep_assert_held() doesn't fire as long as there is a *single*
ww_mutex held of the same class. IOW within a WW transaction.

Code using these mutexes typically want to assert that individual
ww_mutexes are held. Not that any ww_mutex of the same class is
held.

Introduce functions that can be used for that.

RFC: Placement of the functions? lockdep.c? Are the #ifdefs testing for
the correct config?

Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
 include/linux/ww_mutex.h | 18 ++++++++++++++++++
 kernel/locking/mutex.c   | 10 ++++++++++
 2 files changed, 28 insertions(+)

diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 45ff6f7a872b..7bc0f533dea6 100644
--- a/include/linux/ww_mutex.h
+++ b/include/linux/ww_mutex.h
@@ -380,4 +380,22 @@ static inline bool ww_mutex_is_locked(struct ww_mutex *lock)
 	return ww_mutex_base_is_locked(&lock->base);
 }
 
+#ifdef CONFIG_PROVE_LOCKING
+
+bool ww_mutex_held(struct ww_mutex *lock);
+
+#else /* CONFIG_PROVE_LOCKING */
+
+static inline bool ww_mutex_held(struct ww_mutex *lock)
+{
+	return true;
+}
+
+#endif /* CONFIG_PROVE_LOCKING */
+
+static inline void ww_mutex_assert_held(struct ww_mutex *lock)
+{
+	lockdep_assert(ww_mutex_held(lock));
+}
+
 #endif
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index de7d6702cd96..37868b739efd 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -1174,3 +1174,13 @@ int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock)
 	return 1;
 }
 EXPORT_SYMBOL(atomic_dec_and_mutex_lock);
+
+#ifdef CONFIG_PROVE_LOCKING
+
+bool ww_mutex_held(struct ww_mutex *lock)
+{
+	return __ww_mutex_owner(&lock->base) == current;
+}
+EXPORT_SYMBOL(ww_mutex_held);
+
+#endif /* CONFIG_PROVE_LOCKING */
-- 
2.51.1


  reply	other threads:[~2025-11-20 11:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-20 11:03 [RFC PATCH 0/2] locking/ww_mutex, dma-buf/dma-resv: Improve detection of unheld locks Thomas Hellström
2025-11-20 11:03 ` Thomas Hellström [this message]
2025-11-20 11:38   ` [RFC PATCH 1/2] kernel/locking/ww_mutex: Add per-lock lock-check helpers Peter Zijlstra
2025-11-20 11:03 ` [RFC PATCH 2/2] dma-buf/dma-resv: Improve the dma-resv lockdep checks Thomas Hellström
2025-11-20 13:22   ` Christian König
2025-11-20 12:59 ` ✗ CI.checkpatch: warning for locking/ww_mutex, dma-buf/dma-resv: Improve detection of unheld locks Patchwork
2025-11-20 13:01 ` ✓ CI.KUnit: success " Patchwork
2025-11-20 13:19 ` ✗ CI.checksparse: warning " Patchwork
2025-11-20 13:47 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-11-20 16:23 ` ✗ Xe.CI.Full: " Patchwork

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=20251120110341.2425-2-thomas.hellstrom@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=boqun.feng@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sumit.semwal@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.