From: Suren Baghdasaryan <surenb@google.com>
To: akpm@linux-foundation.org
Cc: willy@infradead.org, liam.howlett@oracle.com,
lorenzo.stoakes@oracle.com, mhocko@suse.com, vbabka@suse.cz,
hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com,
mgorman@techsingularity.net, david@redhat.com,
peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net,
paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com,
hdanton@sina.com, hughd@google.com, minchan@google.com,
jannh@google.com, shakeel.butt@linux.dev,
souravpanda@google.com, pasha.tatashin@soleen.com,
corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, kernel-team@android.com,
surenb@google.com
Subject: [PATCH v5 6/6] docs/mm: document latest changes to vm_lock
Date: Fri, 6 Dec 2024 14:52:03 -0800 [thread overview]
Message-ID: <20241206225204.4008261-7-surenb@google.com> (raw)
In-Reply-To: <20241206225204.4008261-1-surenb@google.com>
Change the documentation to reflect that vm_lock is integrated into vma.
Document newly introduced vma_start_read_locked{_nested} functions.
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
Documentation/mm/process_addrs.rst | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/mm/process_addrs.rst b/Documentation/mm/process_addrs.rst
index 81417fa2ed20..92cf497a9e3c 100644
--- a/Documentation/mm/process_addrs.rst
+++ b/Documentation/mm/process_addrs.rst
@@ -716,7 +716,11 @@ calls :c:func:`!rcu_read_lock` to ensure that the VMA is looked up in an RCU
critical section, then attempts to VMA lock it via :c:func:`!vma_start_read`,
before releasing the RCU lock via :c:func:`!rcu_read_unlock`.
-VMA read locks hold the read lock on the :c:member:`!vma->vm_lock` semaphore for
+In cases when the user already holds mmap read lock, :c:func:`!vma_start_read_locked`
+and :c:func:`!vma_start_read_locked_nested` can be used. These functions always
+succeed in acquiring VMA read lock.
+
+VMA read locks hold the read lock on the :c:member:`!vma.vm_lock` semaphore for
their duration and the caller of :c:func:`!lock_vma_under_rcu` must release it
via :c:func:`!vma_end_read`.
@@ -780,7 +784,7 @@ keep VMAs locked across entirely separate write operations. It also maintains
correct lock ordering.
Each time a VMA read lock is acquired, we acquire a read lock on the
-:c:member:`!vma->vm_lock` read/write semaphore and hold it, while checking that
+:c:member:`!vma.vm_lock` read/write semaphore and hold it, while checking that
the sequence count of the VMA does not match that of the mm.
If it does, the read lock fails. If it does not, we hold the lock, excluding
@@ -790,7 +794,7 @@ Importantly, maple tree operations performed in :c:func:`!lock_vma_under_rcu`
are also RCU safe, so the whole read lock operation is guaranteed to function
correctly.
-On the write side, we acquire a write lock on the :c:member:`!vma->vm_lock`
+On the write side, we acquire a write lock on the :c:member:`!vma.vm_lock`
read/write semaphore, before setting the VMA's sequence number under this lock,
also simultaneously holding the mmap write lock.
--
2.47.0.338.g60cca15819-goog
next prev parent reply other threads:[~2024-12-06 22:52 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 22:51 [PATCH v5 0/6] move per-vma lock into vm_area_struct Suren Baghdasaryan
2024-12-06 22:51 ` [PATCH v5 1/6] mm: introduce vma_start_read_locked{_nested} helpers Suren Baghdasaryan
2024-12-10 9:03 ` Vlastimil Babka
2024-12-06 22:51 ` [PATCH v5 2/6] mm: move per-vma lock into vm_area_struct Suren Baghdasaryan
2024-12-10 9:15 ` Vlastimil Babka
2024-12-06 22:52 ` [PATCH v5 3/6] mm: mark vma as detached until it's added into vma tree Suren Baghdasaryan
2024-12-10 9:35 ` Vlastimil Babka
2024-12-10 11:36 ` Vlastimil Babka
2024-12-10 16:28 ` Suren Baghdasaryan
2024-12-06 22:52 ` [PATCH v5 4/6] mm: make vma cache SLAB_TYPESAFE_BY_RCU Suren Baghdasaryan
2024-12-09 17:35 ` Klara Modin
2024-12-09 20:28 ` Suren Baghdasaryan
2024-12-09 22:19 ` Suren Baghdasaryan
2024-12-10 12:06 ` Vlastimil Babka
2024-12-10 16:23 ` Suren Baghdasaryan
2024-12-10 14:21 ` Vlastimil Babka
2024-12-10 16:20 ` Suren Baghdasaryan
2024-12-10 16:32 ` Vlastimil Babka
2024-12-10 17:16 ` Suren Baghdasaryan
2024-12-10 17:25 ` Vlastimil Babka
2024-12-10 18:53 ` Suren Baghdasaryan
2024-12-10 23:01 ` Suren Baghdasaryan
2024-12-11 15:30 ` Suren Baghdasaryan
2024-12-11 16:05 ` Vlastimil Babka
2024-12-11 16:14 ` Suren Baghdasaryan
2024-12-06 22:52 ` [PATCH v5 5/6] mm/slab: allow freeptr_offset to be used with ctor Suren Baghdasaryan
2024-12-10 11:01 ` Vlastimil Babka
2024-12-06 22:52 ` Suren Baghdasaryan [this message]
2024-12-07 3:23 ` [PATCH v5 6/6] docs/mm: document latest changes to vm_lock Randy Dunlap
2024-12-07 4:24 ` Akira Yokosawa
2024-12-07 17:33 ` Suren Baghdasaryan
2024-12-07 4:29 ` [PATCH v5 0/6] move per-vma lock into vm_area_struct Andrew Morton
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=20241206225204.4008261-7-surenb@google.com \
--to=surenb@google.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=dave@stgolabs.net \
--cc=david@redhat.com \
--cc=dhowells@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hdanton@sina.com \
--cc=hughd@google.com \
--cc=jannh@google.com \
--cc=kernel-team@android.com \
--cc=liam.howlett@oracle.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=minchan@google.com \
--cc=mjguzik@gmail.com \
--cc=oleg@redhat.com \
--cc=oliver.sang@intel.com \
--cc=pasha.tatashin@soleen.com \
--cc=paulmck@kernel.org \
--cc=peterx@redhat.com \
--cc=shakeel.butt@linux.dev \
--cc=souravpanda@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.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