lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ