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

From: Lorenzo Stoakes (ARM)

Date: Fri Sep 18 2026 - 09:58:36 EST


On Fri, Sep 18, 2026 at 12:31:50PM +0100, Pedro Falcato wrote:
> On Thu, Sep 17, 2026 at 08:47:43PM +0100, 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.
>
> Hmm, I guess this is where we figure out if "drop the anon rmap" or "insert the
> anon rmap" or "iterate anon rmaps" makes sense, language wise.

Insert: vma->anon_vma = <something>
Drop: vma->anon_vma = NULL
Iterate: iterate over vma->anon_vma

So I think reasonable-ish.

>
> Wouldn't the rmap be the map itself (e.g the current cursed
> anon-vma-anon-vma-chain structure, or in the Glorious Future your remap
> tracking tree)?

A reverse mapping is the folio -> vma mapping so a VMA can possess it or
not.

And the glorious future (TM) will have to track whether this state exists or
not.

In any case, if we change our minds on the naming, we can change it again very
easily in the future :)

>
>
> >
> > 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>
>
> Anyway, you're the native speaker here, so I'll let you decide:

I'm a native speaker compromising on the name I'd actually like to have ;)

is the least-worst alternative right now I think!

>
> Acked-by: Pedro Falcato <pfalcato@xxxxxxx>

Thanks!

>
> Thank you for the series!
>
> --
> Pedro

--
Cheers, Lorenzo