linux-kernel - Re: [PATCH v4 02/10] mm/vma: document possible vma->vm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aaaf33e1-1ef6-4ef8-84e1-c0ae423d8dda@lucifer.local>
Date: Mon, 26 Jan 2026 09:33:05 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        David Hildenbrand <david@...nel.org>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
        Michal Hocko <mhocko@...e.com>, Shakeel Butt <shakeel.butt@...ux.dev>,
        Jann Horn <jannh@...gle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
        Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
        Waiman Long <longman@...hat.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Clark Williams <clrkwllms@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v4 02/10] mm/vma: document possible vma->vm_refcnt values
 and reference comment

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@...cle.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@...cle.com>
>
> One nit, otherwise LGTM:
>
> Reviewed-by: Suren Baghdasaryan <surenb@...gle.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