From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
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: Re: [PATCH RESEND v3 02/10] mm/vma: document possible vma->vm_refcnt values and reference comment
Date: Fri, 23 Jan 2026 13:45:02 +0000 [thread overview]
Message-ID: <b5e16d20-0ed6-401f-9c01-8efa35c49f64@lucifer.local> (raw)
In-Reply-To: <7876e97c-9afb-418a-8ef7-5f4f306b7eea@suse.cz>
On Thu, Jan 22, 2026 at 05:48:07PM +0100, Vlastimil Babka wrote:
> On 1/22/26 14:01, Lorenzo Stoakes 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>
>
> Thanks, very useful. Forgive my nitpicks :) It's because it's tricky so best
> try to be as precise as possible, I believe.
Ack.
>
> > ---
> > include/linux/mm_types.h | 39 +++++++++++++++++++++++++++++++++++++--
> > include/linux/mmap_lock.h | 7 +++++++
> > mm/mmap_lock.c | 6 ++++++
> > 3 files changed, 50 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 94de392ed3c5..e5ee66f84d9a 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,41 @@ 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 the number of references taken by VMA read or
> > + * write locks. May have the VM_REFCNT_EXCLUDE_READERS_FLAG set
>
> I wonder about the "or write locks" part. The process of acquiring it uses
> VM_REFCNT_EXCLUDE_READERS_FLAG but then the writer doesn't hold a 1
> refcount? (the sentence could be read it way IMHO) It's vma being attached
> that does, AFAIK?
Right the intent is to say that, in the process of excluding readers, a write
lock can vary the reference count.
It's a pity we can't describe the refcnt in some sensible, logical way as it's
really being overloaded quite a bit for multiple things.
It really isn't actually keeping track of references (other than read locks
taken).
OK so I have updated this to say:
* 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.
>
> > + * indicating that a thread has entered __vma_enter_locked() and is
> > + * waiting on any outstanding read locks to exit.
> > + *
> > + * This value can be equal to:
> > + *
> > + * 0 - Detached.
>
> Is it worth saying that readers can't increment the refcount?
Added, updated to say:
* 0 - Detached. IMPORTANT: when the refcnt is zero, readers cannot
* increment it.
>
> > + * 1 - Unlocked or write-locked.
>
> "Attached and either unlocked or write-locked." ?
>
> (see how "write-locked" isn't reflected, I argued above)
I'm not sure what you mean, a write lock requires the VMA to be attached (or it
bails out on attempted write lock). So it's kind of implicit right?
But yes better to be explicit, so have replaced with your suggestion.
>
> > + *
> > + * >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.
>
> Ack.
>
> > + * 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 - Either an attached VMA pending
> > + * __vma_exit_locked() completion which will decrement the reference
> > + * count to one, OR a detached VMA waiting on a single spurious reader
> > + * to decrement reference count. IMPORTANT - as above, no further
> > + * readers can increment the reference count.
> > + *
> > + * > VM_REFCNT_EXCLUDE_READERS_FLAG + 1 - VMA is waiting on readers,
>
> "VMA is waiting" sounds weird? a thread might be, but VMA itself?
> (similarly in the previous paragraph)
I was trying to make it a bit more succinct that way I think, but agreed
it's unclear. Have replaced with:
* 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 either
* write-locking or detaching a VMA is waiting on readers to
* exit. IMPORTANT - as above, no ruther readers can increment the
* reference count.
Cheers, Lorenzo
next prev parent reply other threads:[~2026-01-23 13:45 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 13:01 [PATCH RESEND v3 00/10] mm: add and use vma_assert_stabilised() helper Lorenzo Stoakes
2026-01-22 13:01 ` [PATCH RESEND v3 01/10] mm/vma: rename VMA_LOCK_OFFSET to VM_REFCNT_EXCLUDE_READERS_FLAG Lorenzo Stoakes
2026-01-22 16:26 ` Vlastimil Babka
2026-01-22 16:29 ` Lorenzo Stoakes
2026-01-23 13:52 ` Lorenzo Stoakes
2026-01-22 16:37 ` Suren Baghdasaryan
2026-01-23 13:26 ` Lorenzo Stoakes
2026-01-22 13:01 ` [PATCH RESEND v3 02/10] mm/vma: document possible vma->vm_refcnt values and reference comment Lorenzo Stoakes
2026-01-22 16:48 ` Vlastimil Babka
2026-01-22 17:28 ` Suren Baghdasaryan
2026-01-23 15:06 ` Lorenzo Stoakes
2026-01-23 13:45 ` Lorenzo Stoakes [this message]
2026-01-22 13:01 ` [PATCH RESEND v3 03/10] mm/vma: rename is_vma_write_only(), separate out shared refcount put Lorenzo Stoakes
2026-01-22 17:36 ` Vlastimil Babka
2026-01-22 19:31 ` Suren Baghdasaryan
2026-01-23 8:24 ` Vlastimil Babka
2026-01-23 14:52 ` Lorenzo Stoakes
2026-01-23 15:05 ` Vlastimil Babka
2026-01-23 15:07 ` Lorenzo Stoakes
2026-01-23 14:41 ` Lorenzo Stoakes
2026-01-26 10:04 ` Lorenzo Stoakes
2026-01-23 14:02 ` Lorenzo Stoakes
2026-01-22 13:01 ` [PATCH RESEND v3 04/10] mm/vma: add+use vma lockdep acquire/release defines Lorenzo Stoakes
2026-01-22 19:32 ` Suren Baghdasaryan
2026-01-22 19:41 ` Suren Baghdasaryan
2026-01-23 8:41 ` Vlastimil Babka
2026-01-23 15:08 ` Lorenzo Stoakes
2026-01-23 15:00 ` Lorenzo Stoakes
2026-01-23 8:48 ` Vlastimil Babka
2026-01-23 15:10 ` Lorenzo Stoakes
2026-01-22 13:01 ` [PATCH RESEND v3 05/10] mm/vma: de-duplicate __vma_enter_locked() error path Lorenzo Stoakes
2026-01-22 19:39 ` Suren Baghdasaryan
2026-01-23 15:11 ` Lorenzo Stoakes
2026-01-23 8:54 ` Vlastimil Babka
2026-01-23 15:10 ` Lorenzo Stoakes
2026-01-22 13:01 ` [PATCH v3 06/10] mm/vma: clean up __vma_enter/exit_locked() Lorenzo Stoakes
2026-01-22 13:08 ` Lorenzo Stoakes
2026-01-22 20:15 ` Suren Baghdasaryan
2026-01-22 20:55 ` Andrew Morton
2026-01-23 16:15 ` Lorenzo Stoakes
2026-01-23 16:33 ` Lorenzo Stoakes
2026-01-23 9:16 ` Vlastimil Babka
2026-01-23 16:17 ` Lorenzo Stoakes
2026-01-23 16:28 ` Lorenzo Stoakes
2026-01-22 13:01 ` [PATCH RESEND v3 07/10] mm/vma: introduce helper struct + thread through exclusive lock fns Lorenzo Stoakes
2026-01-22 21:41 ` Suren Baghdasaryan
2026-01-23 17:59 ` Lorenzo Stoakes
2026-01-23 19:34 ` Suren Baghdasaryan
2026-01-23 20:04 ` Lorenzo Stoakes
2026-01-23 22:07 ` Suren Baghdasaryan
2026-01-24 8:54 ` Lorenzo Stoakes
2026-01-26 6:09 ` Suren Baghdasaryan
2026-01-23 10:02 ` Vlastimil Babka
2026-01-23 18:18 ` Lorenzo Stoakes
2026-01-22 13:02 ` [PATCH RESEND v3 08/10] mm/vma: improve and document __is_vma_write_locked() Lorenzo Stoakes
2026-01-22 21:55 ` Suren Baghdasaryan
2026-01-23 16:21 ` Vlastimil Babka
2026-01-23 17:42 ` Suren Baghdasaryan
2026-01-23 18:44 ` Lorenzo Stoakes
2026-01-22 13:02 ` [PATCH RESEND v3 09/10] mm/vma: update vma_assert_locked() to use lockdep Lorenzo Stoakes
2026-01-22 22:02 ` Suren Baghdasaryan
2026-01-23 18:45 ` Lorenzo Stoakes
2026-01-23 16:55 ` Vlastimil Babka
2026-01-23 18:49 ` Lorenzo Stoakes
2026-01-22 13:02 ` [PATCH RESEND v3 10/10] mm/vma: add and use vma_assert_stabilised() Lorenzo Stoakes
2026-01-22 22:12 ` Suren Baghdasaryan
2026-01-23 18:54 ` Lorenzo Stoakes
2026-01-23 17:10 ` Vlastimil Babka
2026-01-23 18:51 ` Lorenzo Stoakes
2026-01-23 23:35 ` Hillf Danton
2026-01-22 15:48 ` [PATCH RESEND v3 00/10] mm: add and use vma_assert_stabilised() helper Andrew Morton
2026-01-22 15:57 ` Lorenzo Stoakes
2026-01-22 16:01 ` 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=b5e16d20-0ed6-401f-9c01-8efa35c49f64@lucifer.local \
--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