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

["Zi Yan" <ziy@nvidia.com>]

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@kernel.org>
> ---
>  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/

<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. ;)

>  	 * 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@nvidia.com>


-- 
Best Regards,
Yan, Zi