Re: [PATCH v3 3/3] mm: update comments to refer to anon rmap rather than anon_vma

[Lorenzo Stoakes (ARM)]

On Thu, Sep 17, 2026 at 04:43:15PM -0400, Zi Yan wrote:
> On Thu Sep 17, 2026 at 3:47 PM EDT, Lorenzo Stoakes (ARM) wrote:
> > Now that vma_has_anon_rmap() abstracts whether a VMA has an anonymous
> > reverse mapping, remove references to anon_vma and instead reference the
> > anon rmap.
> >
> > The anon_vma is an implementation detail and should be treated as such.
> >
> > Do not update mm/rmap.c which implements the anon_vma mechanism as it is
> > reasonable to directly reference it there.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> > ---
> >  mm/huge_memory.c     | 17 +++++----
> >  mm/hugetlb.c         |  2 +-
> >  mm/khugepaged.c      | 12 +++----
> >  mm/ksm.c             |  6 ++--
> >  mm/madvise.c         |  6 ++--
> >  mm/memory.c          | 12 +++----
> >  mm/migrate.c         | 12 +++----
> >  mm/mmap.c            |  6 ++--
> >  mm/mprotect.c        |  4 +--
> >  mm/mremap.c          |  6 ++--
> >  mm/pgtable-generic.c |  2 +-
> >  mm/userfaultfd.c     | 10 +++---
> >  mm/vma.c             | 98 ++++++++++++++++++++++++++--------------------------
> >  13 files changed, 96 insertions(+), 97 deletions(-)
> >
> > @@ -4176,11 +4176,10 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> >  	if (is_anon) {
> >  		/*
> >  		 * The caller does not necessarily hold an mmap_lock that would
> > -		 * prevent the anon_vma disappearing so we first we take a
> > -		 * reference to it and then lock the anon_vma for write. This
> > -		 * is similar to folio_lock_anon_vma_read except the write lock
> > -		 * is taken to serialise against parallel split or collapse
> > -		 * operations.
> > +		 * prevent the anon rmap disappearing so we first we take a
>
> s/we first we/we first/

We first, we happy few, first we take a lock that we have on... ok
no. No. You're right :P

Andrew could you fix up?

>
> <snip>
>
> > @@ -1619,7 +1619,7 @@ static int try_to_merge_with_ksm_page(struct ksm_rmap_item *rmap_item,
> >
> >  	/*
> >  	 * We can consider the VMA only while still holding the mmap lock,
> > -	 * so lock, so reference the anon_vma and calculate the linear
> > +	 * so lock, so reference the anon rmap and calculate the linear
>
> s/so lock,//

>
> based on the code after this comment. Please double check it. And it is
> a pre-existing typo in the comment. Hmm, it sounds very Sashiko. ;)

So Zi was sashiko all along... interesting ;)

Andrew - could you fix this up too?

>
> >  	 * page index early, before stable_tree_append(). If anything goes
> >  	 * wrong that prevents the rmap_item from being added to the
> >  	 * stable_tree, break_cow() will clean it up.
>
>
> Otherwise, LGTM.
>
> Reviewed-by: Zi Yan <ziy@xxxxxxxxxx>

Thanks!

>
>
> --
> Best Regards,
> Yan, Zi
>

--
Cheers, Lorenzo