Re: [PATCH v4 02/10] mm/vma: document possible vma->vm_refcnt values and reference comment

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

Andrew - could you fix up the typo below? If a pain I can send a fix-patch
thanks :)

On Sun, Jan 25, 2026 at 09:15:04PM -0800, Suren Baghdasaryan wrote:
> On Fri, Jan 23, 2026 at 12:12 PM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > The possible vma->vm_refcnt values are confusing and vague, explain in
> > detail what these can be in a comment describing the vma->vm_refcnt field
> > and reference this comment in various places that read/write this field.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>
> One nit, otherwise LGTM:
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>

Thanks!

>
> > ---
> >  include/linux/mm_types.h  | 42 +++++++++++++++++++++++++++++++++++++--
> >  include/linux/mmap_lock.h |  7 +++++++
> >  mm/mmap_lock.c            |  6 ++++++
> >  3 files changed, 53 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index bdbf17c4f26b..12281a1128c9 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -758,7 +758,8 @@ static inline struct anon_vma_name *anon_vma_name_alloc(const char *name)
> >   * set the VM_REFCNT_EXCLUDE_READERS_FLAG in vma->vm_refcnt to indiciate to
> >   * vma_start_read() that the reference count should be left alone.
> >   *
> > - * Once the operation is complete, this value is subtracted from vma->vm_refcnt.
> > + * See the comment describing vm_refcnt in vm_area_struct for details as to
> > + * which values the VMA reference count can be.
> >   */
> >  #define VM_REFCNT_EXCLUDE_READERS_BIT  (30)
> >  #define VM_REFCNT_EXCLUDE_READERS_FLAG (1U << VM_REFCNT_EXCLUDE_READERS_BIT)
> > @@ -989,7 +990,44 @@ struct vm_area_struct {
> >         struct vma_numab_state *numab_state;    /* NUMA Balancing state */
> >  #endif
> >  #ifdef CONFIG_PER_VMA_LOCK
> > -       /* Unstable RCU readers are allowed to read this. */
> > +       /*
> > +        * Used to keep track of firstly, whether the VMA is attached, secondly,
> > +        * if attached, how many read locks are taken, and thirdly, if the
> > +        * VM_REFCNT_EXCLUDE_READERS_FLAG is set, whether any read locks held
> > +        * are currently in the process of being excluded.
> > +        *
> > +        * This value can be equal to:
> > +        *
> > +        * 0 - Detached. IMPORTANT: when the refcnt is zero, readers cannot
> > +        * increment it.
> > +        *
> > +        * 1 - Attached and either unlocked or write-locked. Write locks are
> > +        * identified via __is_vma_write_locked() which checks for equality of
> > +        * vma->vm_lock_seq and mm->mm_lock_seq.
> > +        *
> > +        * >1, < VM_REFCNT_EXCLUDE_READERS_FLAG - Read-locked or (unlikely)
> > +        * write-locked with other threads having temporarily incremented the
> > +        * reference count prior to determining it is write-locked and
> > +        * decrementing it again.
> > +        *
> > +        * VM_REFCNT_EXCLUDE_READERS_FLAG - Detached, pending
> > +        * __vma_exit_locked() completion which will decrement the reference
> > +        * count to zero. IMPORTANT - at this stage no further readers can
> > +        * increment the reference count. It can only be reduced.
> > +        *
> > +        * VM_REFCNT_EXCLUDE_READERS_FLAG + 1 - A thread is either write-locking
> > +        * an attached VMA and has yet to invoke __vma_exit_locked(), OR a
> > +        * thread is detaching a VMA and is waiting on a single spurious reader
> > +        * in order to decrement the reference count. IMPORTANT - as above, no
> > +        * further readers can increment the reference count.
> > +        *
> > +        * > VM_REFCNT_EXCLUDE_READERS_FLAG + 1 - A thread is either
> > +        * write-locking or detaching a VMA is waiting on readers to
> > +        * exit. IMPORTANT - as above, no ruther readers can increment the
>
> s/ruther/further

You're depriving newer kernel people of typo fixup series which is, of course,
why I leave these in patches *ahem* :P

Thanks, hopefully Andrew can fix up trivially!

Cheers, Lorenzo