From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
Jann Horn <jannh@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev,
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>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Clark Williams <clrkwllms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>
Subject: [PATCH v2 1/2] mm/vma: use lockdep where we can, reduce duplication
Date: Mon, 19 Jan 2026 20:59:39 +0000 [thread overview]
Message-ID: <bd410fd91d22eef37f9b617327cafce33b267b09.1768855783.git.lorenzo.stoakes@oracle.com> (raw)
In-Reply-To: <cover.1768855783.git.lorenzo.stoakes@oracle.com>
We introduce vma_is_read_locked(), which must deal with the case in which
VMA write lock sets refcnt to VMA_LOCK_OFFSET or VMA_LOCK_OFFSET +
1. Luckily is_vma_writer_only() already exists which we can use to check
this.
We then try to make vma_assert_locked() use lockdep as far as we can.
Unfortunately the VMA lock implementation does not even try to track VMA
write locks using lockdep, so we cannot track the lock this way.
This is less egregious than it might seem as VMA write locks are predicated
on mmap write locks, which we do lockdep assert.
vma_assert_write_locked() already asserts the mmap write lock is taken so
we get that checked implicitly.
However for read locks we do indeed use lockdup, via rwsem_acquire_read()
called in vma_start_read() and rwsem_release_read() called in
vma_refcount_put() called in turn by vma_end_read().
Therefore we perform a lockdep assertion if the VMA is known to be
read-locked.
If it is write-locked, we assert the mmap lock instead, with a lockdep
check if lockdep is enabled.
If lockdep is not enabled, we just check that locks are in place.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
include/linux/mmap_lock.h | 34 ++++++++++++++++++++++++++++++----
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
index b50416fbba20..6979222882f1 100644
--- a/include/linux/mmap_lock.h
+++ b/include/linux/mmap_lock.h
@@ -236,6 +236,13 @@ int vma_start_write_killable(struct vm_area_struct *vma)
return __vma_start_write(vma, mm_lock_seq, TASK_KILLABLE);
}
+static inline bool vma_is_read_locked(const struct vm_area_struct *vma)
+{
+ const unsigned int refcnt = refcount_read(&vma->vm_refcnt);
+
+ return refcnt > 1 && !is_vma_writer_only(refcnt);
+}
+
static inline void vma_assert_write_locked(struct vm_area_struct *vma)
{
unsigned int mm_lock_seq;
@@ -243,12 +250,31 @@ static inline void vma_assert_write_locked(struct vm_area_struct *vma)
VM_BUG_ON_VMA(!__is_vma_write_locked(vma, &mm_lock_seq), vma);
}
+/**
+ * vma_assert_locked() - Assert that @vma is either read or write locked and
+ * that we have ownership of that lock (if lockdep is enabled).
+ * @vma: The VMA we assert.
+ *
+ * If lockdep is enabled, we ensure ownership of the VMA lock. Otherwise we
+ * assert that we are VMA write-locked, which implicitly asserts that we hold
+ * the mmap write lock.
+ */
static inline void vma_assert_locked(struct vm_area_struct *vma)
{
- unsigned int mm_lock_seq;
-
- VM_BUG_ON_VMA(refcount_read(&vma->vm_refcnt) <= 1 &&
- !__is_vma_write_locked(vma, &mm_lock_seq), vma);
+ /*
+ * VMA locks currently only utilise lockdep for read locks, as
+ * vma_end_write_all() releases an unknown number of VMA write locks and
+ * we don't currently walk the maple tree to identify which locks are
+ * released even under CONFIG_LOCKDEP.
+ *
+ * However, VMA write locks are predicated on an mmap write lock, which
+ * we DO track under lockdep, and which vma_assert_write_locked()
+ * asserts.
+ */
+ if (vma_is_read_locked(vma))
+ lockdep_assert(lock_is_held(&vma->vmlock_dep_map));
+ else
+ vma_assert_write_locked(vma);
}
static inline bool vma_is_attached(struct vm_area_struct *vma)
--
2.52.0
next prev parent reply other threads:[~2026-01-19 21:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 20:59 [PATCH v2 0/2] add and use vma_assert_stabilised() helper Lorenzo Stoakes
2026-01-19 20:59 ` Lorenzo Stoakes [this message]
2026-01-20 13:53 ` [PATCH v2 1/2] mm/vma: use lockdep where we can, reduce duplication Vlastimil Babka
2026-01-20 17:49 ` Lorenzo Stoakes
2026-01-20 21:28 ` Vlastimil Babka
2026-01-21 9:07 ` Lorenzo Stoakes
2026-01-19 20:59 ` [PATCH v2 2/2] mm: add vma_assert_stabilised() Lorenzo Stoakes
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=bd410fd91d22eef37f9b617327cafce33b267b09.1768855783.git.lorenzo.stoakes@oracle.com \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=clrkwllms@kernel.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=longman@redhat.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--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