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 v3 00/10] mm: add and use vma_assert_stabilised() helper
Date: Thu, 22 Jan 2026 12:50:20 +0000 [thread overview]
Message-ID: <cover.1769085814.git.lorenzo.stoakes@oracle.com> (raw)
Sometimes we wish to assert that a VMA is stable, that is - the VMA cannot
be changed underneath us. This will be the case if EITHER the VMA lock or
the mmap lock is held.
We already open-code this in two places - anon_vma_name() in mm/madvise.c
and vma_flag_set_atomic() in include/linux/mm.h.
This series adds vma_assert_stablised() which abstract this can be used in
these callsites instead.
This implementation uses lockdep where possible - that is VMA read locks -
which correctly track read lock acquisition/release via:
vma_start_read() ->
rwsem_acquire_read()
vma_start_read_locked() ->
vma_start_read_locked_nested() ->
rwsem_acquire_read()
And:
vma_end_read() ->
vma_refcount_put() ->
rwsem_release()
We don't track the VMA locks using lockdep for VMA write locks, however
these are predicated upon mmap write locks whose lockdep state we do track,
and additionally vma_assert_stabillised() asserts this check if VMA read
lock is not held, so we get lockdep coverage in this case also.
We also add extensive comments to describe what we're doing.
There's some tricky stuff around mmap locking and stabilisation races that
we have to be careful of that I describe in the patch introducing
vma_assert_stabilised().
This change also lays the foundation for future series to add this assert
in further places where we wish to make it clear that we rely upon a
stabilised VMA.
The motivation for this change was precisely this.
Addiitonally, refactor the VMA locks logic to be clearer, less confusing,
self-documenting as far as possible and more easily extendable and
debuggable in future.
v3:
* Added 8 patches of refactoring the VMA lock implementation :)
* Dropped the vma_is_*locked() predicates as too difficult to get entirely
right.
* Updated vma_assert_locked() to assert what we sensibly can, use lockdep
if possible and invoke vma_assert_write_locked() to share code as before.
* Took into account extensive feedback received from Vlastimil (thanks! :)
v2:
* Added lockdep as much as possible to the mix as per Peter and Sebastian.
* Added comments to make clear what we're doing in each case.
* I realise I made a mistake in saying the previous duplicative VMA stable
asserts were wrong - vma_assert_locked() is not a no-op if
!CONFIG_PER_VMA_LOCK, instead it degrades to asserting that the mmap lock
is held, so this is correct, though means we'd have checked this twice,
only triggering an assert the second time.
* Accounted for is_vma_writer_only() case in vma_is_read_locked().
* Accounted for two hideous issues - we cannot check VMA lock first,
because we may be holding a VMA write lock and be raced by VMA readers of
_other_ VMA's. If we check the mmap lock first and assert, we may hold a
VMA read lock and race other threads which hodl the mmap read lock and
fail an assert. We resolve this by a precise mmap ownership check if
lockdep is used, and allowing the check to be approximate if no lockdep.
* Added more comments and updated commit logs.
* Dropped Suren's Suggested-by as significant changes in this set (this was for
the vma_is_read_locked() as a concept).
https://lore.kernel.org/all/cover.1768855783.git.lorenzo.stoakes@oracle.com/
v1:
https://lore.kernel.org/all/cover.1768569863.git.lorenzo.stoakes@oracle.com/
Lorenzo Stoakes (8):
mm/vma: rename VMA_LOCK_OFFSET to VM_REFCNT_EXCLUDE_READERS_FLAG
mm/vma: document possible vma->vm_refcnt values and reference comment
mm/vma: rename is_vma_write_only(), separate out shared refcount put
mm/vma: add+use vma lockdep acquire/release defines
mm/vma: de-duplicate __vma_enter_locked() error path
mm/vma: clean up __vma_enter/exit_locked()
mm/vma: introduce helper struct + thread through exclusive lock fns
mm/vma: improve and document __is_vma_write_locked()
include/linux/mm_types.h | 54 ++++++++++--
include/linux/mmap_lock.h | 129 ++++++++++++++++++++++-----
mm/mmap_lock.c | 180 ++++++++++++++++++++++++++------------
3 files changed, 280 insertions(+), 83 deletions(-)
--
2.52.0
next reply other threads:[~2026-01-22 12:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 12:50 Lorenzo Stoakes [this message]
2026-01-22 12:50 ` [PATCH v3 1/8] mm/vma: rename VMA_LOCK_OFFSET to VM_REFCNT_EXCLUDE_READERS_FLAG Lorenzo Stoakes
2026-01-22 12:50 ` [PATCH v3 2/8] mm/vma: document possible vma->vm_refcnt values and reference comment Lorenzo Stoakes
2026-01-22 12:50 ` [PATCH v3 3/8] mm/vma: rename is_vma_write_only(), separate out shared refcount put Lorenzo Stoakes
2026-01-22 18:07 ` Suren Baghdasaryan
2026-01-22 12:50 ` [PATCH v3 4/8] mm/vma: add+use vma lockdep acquire/release defines Lorenzo Stoakes
2026-01-22 19:25 ` Suren Baghdasaryan
2026-01-22 12:50 ` [PATCH v3 5/8] mm/vma: de-duplicate __vma_enter_locked() error path Lorenzo Stoakes
2026-01-22 12:50 ` [PATCH v3 6/8] mm/vma: clean up __vma_enter/exit_locked() Lorenzo Stoakes
2026-01-22 12:50 ` [PATCH v3 7/8] mm/vma: introduce helper struct + thread through exclusive lock fns Lorenzo Stoakes
2026-01-22 12:50 ` [PATCH v3 8/8] mm/vma: improve and document __is_vma_write_locked() Lorenzo Stoakes
2026-01-22 12:55 ` [PATCH v3 00/10] mm: add and use vma_assert_stabilised() helper 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=cover.1769085814.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