This function is confusing, we already have the concept of anon_vma merge
to adjacent VMA's anon_vma's to increase probability of anon_vma
compatibility and therefore VMA merge (see is_mergeable_anon_vma() etc.),
as well as anon_vma reuse, along side the usual VMA merge logic.
We can remove the anon_vma check as it is redundant - a merge would not
have been permitted with removal if the anon_vma's were not the same (and
in the case of an unfaulted/faulted merge, we would have already set the
unfaulted VMA's anon_vma to vp->remove->anon_vma in dup_anon_vma()).
Avoid overloading this term when we're very simply unlinking anon_vma state
from a removed VMA upon merge.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
include/linux/rmap.h | 7 -------
mm/vma.c | 2 +-
tools/testing/vma/vma_internal.h | 5 -----
3 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index daa92a58585d..832bfc0ccfc6 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -165,13 +165,6 @@ static inline int anon_vma_prepare(struct vm_area_struct *vma)
return __anon_vma_prepare(vma);
}
-static inline void anon_vma_merge(struct vm_area_struct *vma,
- struct vm_area_struct *next)
-{
- VM_BUG_ON_VMA(vma->anon_vma != next->anon_vma, vma);
- unlink_anon_vmas(next);
-}
-
struct anon_vma *folio_get_anon_vma(const struct folio *folio);
#ifdef CONFIG_MM_ID
diff --git a/mm/vma.c b/mm/vma.c
index fc90befd162f..feb4bbd3b259 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -376,7 +376,7 @@ static void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi,
fput(vp->file);
}
if (vp->remove->anon_vma)
- anon_vma_merge(vp->vma, vp->remove);
+ unlink_anon_vmas(vp->remove);
mm->map_count--;
mpol_put(vma_policy(vp->remove));
if (!vp->remove2)
diff --git a/tools/testing/vma/vma_internal.h b/tools/testing/vma/vma_internal.h
index 9f0a9f5ed0fe..93e5792306d9 100644
--- a/tools/testing/vma/vma_internal.h
+++ b/tools/testing/vma/vma_internal.h
@@ -1265,11 +1265,6 @@ static inline void i_mmap_unlock_write(struct address_space *mapping)
{
}
-static inline void anon_vma_merge(struct vm_area_struct *vma,
- struct vm_area_struct *next)
-{
-}
-
static inline int userfaultfd_unmap_prep(struct vm_area_struct *vma,
unsigned long start,
unsigned long end,
--
2.52.0
On Wed, Dec 17, 2025 at 4:27 AM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> This function is confusing, we already have the concept of anon_vma merge
> to adjacent VMA's anon_vma's to increase probability of anon_vma
> compatibility and therefore VMA merge (see is_mergeable_anon_vma() etc.),
> as well as anon_vma reuse, along side the usual VMA merge logic.
>
> We can remove the anon_vma check as it is redundant - a merge would not
> have been permitted with removal if the anon_vma's were not the same (and
> in the case of an unfaulted/faulted merge, we would have already set the
> unfaulted VMA's anon_vma to vp->remove->anon_vma in dup_anon_vma()).
>
> Avoid overloading this term when we're very simply unlinking anon_vma state
> from a removed VMA upon merge.
>
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> ---
> include/linux/rmap.h | 7 -------
> mm/vma.c | 2 +-
> tools/testing/vma/vma_internal.h | 5 -----
> 3 files changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> index daa92a58585d..832bfc0ccfc6 100644
> --- a/include/linux/rmap.h
> +++ b/include/linux/rmap.h
> @@ -165,13 +165,6 @@ static inline int anon_vma_prepare(struct vm_area_struct *vma)
> return __anon_vma_prepare(vma);
> }
>
> -static inline void anon_vma_merge(struct vm_area_struct *vma,
> - struct vm_area_struct *next)
> -{
> - VM_BUG_ON_VMA(vma->anon_vma != next->anon_vma, vma);
> - unlink_anon_vmas(next);
> -}
> -
> struct anon_vma *folio_get_anon_vma(const struct folio *folio);
>
> #ifdef CONFIG_MM_ID
> diff --git a/mm/vma.c b/mm/vma.c
> index fc90befd162f..feb4bbd3b259 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -376,7 +376,7 @@ static void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi,
> fput(vp->file);
> }
> if (vp->remove->anon_vma)
> - anon_vma_merge(vp->vma, vp->remove);
> + unlink_anon_vmas(vp->remove);
> mm->map_count--;
> mpol_put(vma_policy(vp->remove));
> if (!vp->remove2)
> diff --git a/tools/testing/vma/vma_internal.h b/tools/testing/vma/vma_internal.h
> index 9f0a9f5ed0fe..93e5792306d9 100644
> --- a/tools/testing/vma/vma_internal.h
> +++ b/tools/testing/vma/vma_internal.h
> @@ -1265,11 +1265,6 @@ static inline void i_mmap_unlock_write(struct address_space *mapping)
> {
> }
>
> -static inline void anon_vma_merge(struct vm_area_struct *vma,
> - struct vm_area_struct *next)
> -{
> -}
> -
> static inline int userfaultfd_unmap_prep(struct vm_area_struct *vma,
> unsigned long start,
> unsigned long end,
> --
> 2.52.0
On Tue, Dec 30, 2025 at 11:35:02AM -0800, Suren Baghdasaryan wrote: > On Wed, Dec 17, 2025 at 4:27 AM Lorenzo Stoakes > <lorenzo.stoakes@oracle.com> wrote: > > > > This function is confusing, we already have the concept of anon_vma merge > > to adjacent VMA's anon_vma's to increase probability of anon_vma > > compatibility and therefore VMA merge (see is_mergeable_anon_vma() etc.), > > as well as anon_vma reuse, along side the usual VMA merge logic. > > > > We can remove the anon_vma check as it is redundant - a merge would not > > have been permitted with removal if the anon_vma's were not the same (and > > in the case of an unfaulted/faulted merge, we would have already set the > > unfaulted VMA's anon_vma to vp->remove->anon_vma in dup_anon_vma()). > > > > Avoid overloading this term when we're very simply unlinking anon_vma state > > from a removed VMA upon merge. > > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > > Reviewed-by: Suren Baghdasaryan <surenb@google.com> Thanks!
© 2016 - 2026 Red Hat, Inc.