On Tue, Nov 12, 2024 at 11:51:47AM -0800, Suren Baghdasaryan wrote:
> On Tue, Nov 12, 2024 at 11:47 AM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
> >
> > 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@xxxxxxxxxx>
Thanks!
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
>
> Sorry, forgot to CC Mr. Corbet and linux-doc@vger. Added now.
>
> > ---
> > 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 ed74685ffbf2..c8935509173e 100644
> > --- a/Documentation/mm/process_addrs.rst
> > +++ b/Documentation/mm/process_addrs.rst
> > @@ -675,7 +675,11 @@ 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`.
> >
> > @@ -739,7 +743,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
> > @@ -749,7 +753,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.277.g8800431eea-goog
> >
