Re: [PATCH v2 08/33] mm/rmap: rename vma_interval_tree_*() to mapping_rmap_tree_*()

From: Lorenzo Stoakes (ARM)

Date: Mon Jul 20 2026 - 03:24:40 EST


On Fri, Jul 17, 2026 at 10:54:24PM -0400, Zi Yan wrote:
> On Fri Jul 10, 2026 at 4:16 PM EDT, Lorenzo Stoakes wrote:
> > The family of vma_interval_tree_() functions manipulate the
> > address_space (which, of course, is generally referred to as 'mapping')
> > reverse mapping, but are named the 'VMA' interval tree.
> >
> > VMAs may be mapped by an anon_vma, an address_space, or both. Therefore
> > calling the mapping interval tree a 'VMA' interval tree is rather
> > confusing.
> >
> > This is also inconsistent with the anon_vma_interval_tree_*() functions
> > which explicitly reference the rmap object to which they pertain.
> >
> > Rename the vma_interval_tree_*() functions to mapping_rmap_tree_*() to
> > correct this.
> >
> > We will rename the anon rmap functions similarly in a subsequent patch.
> >
> > No functional change intended.
> >
> > Reviewed-by: Gregory Price <gourry@xxxxxxxxxx>
> > Signed-off-by: Lorenzo Stoakes <ljs@xxxxxxxxxx>
> > ---
> > arch/arm/mm/fault-armv.c | 2 +-
> > arch/arm/mm/flush.c | 2 +-
> > arch/nios2/mm/cacheflush.c | 2 +-
> > arch/parisc/kernel/cache.c | 2 +-
> > fs/dax.c | 2 +-
> > fs/hugetlbfs/inode.c | 4 ++--
> > include/linux/mm.h | 16 ++++++++--------
> > kernel/events/uprobes.c | 2 +-
> > mm/hugetlb.c | 4 ++--
> > mm/interval_tree.c | 22 +++++++++++-----------
> > mm/khugepaged.c | 4 ++--
> > mm/memory-failure.c | 6 +++---
> > mm/memory.c | 2 +-
> > mm/mmap.c | 2 +-
> > mm/nommu.c | 8 ++++----
> > mm/pagewalk.c | 2 +-
> > mm/rmap.c | 2 +-
> > mm/vma.c | 12 ++++++------
> > tools/testing/vma/include/stubs.h | 4 ++--
> > 19 files changed, 50 insertions(+), 50 deletions(-)
> >
>
> Just curious, why not file_rmap_tree_*()?

Just to avoid any confusion around address_space objects that are ostensibly
'not files' like devices or whatnot, but moreso for consistency with the rest of
the kernel in referring to this stuff as 'mapping'.

Naming is hard IOW :)

>
> One nice part of this renaming is that the length of each function does
> not chagne. That makes the patch easy to review.
>
> Reviewed-by: Zi Yan <ziy@xxxxxxxxxx>

Thanks!

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

Cheers, Lorenzo