[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <79d15f9e-2a4e-43cd-9004-a56cb0945c35@lucifer.local>
Date: Tue, 6 Jan 2026 14:00:50 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>,
Shakeel Butt <shakeel.butt@...ux.dev>,
David Hildenbrand <david@...nel.org>, Rik van Riel <riel@...riel.com>,
Harry Yoo <harry.yoo@...cle.com>, Jann Horn <jannh@...gle.com>,
Mike Rapoport <rppt@...nel.org>, Michal Hocko <mhocko@...e.com>,
Pedro Falcato <pfalcato@...e.de>, Chris Li <chriscli@...gle.com>,
Barry Song <v-songbaohua@...o.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/8] mm/rmap: remove anon_vma_merge() function
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@...cle.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@...cle.com>
>
> Reviewed-by: Suren Baghdasaryan <surenb@...gle.com>
Thanks!
Powered by blists - more mailing lists