linux-kernel - Re: [PATCH v2 1/8] mm/rmap: improve anon_vma_clone(), unlink_anon

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: <6fb9d6b4-ad39-41de-8db0-aa41a6406378@lucifer.local>
Date: Wed, 14 Jan 2026 19:02:20 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Suren Baghdasaryan <surenb@...gle.com>,
        "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 v2 1/8] mm/rmap: improve anon_vma_clone(),
 unlink_anon_vmas() comments, add asserts

Hi Andrew,

Can you apply the below fix-patch to this to fix up a rather silly
failure-to-unlock mistake that Suren picked up on?

Luckily this partial unmap function is unlikely to ever be triggerable in real
life, AND more to the point - a later patch completely eliminates the locking -
but to avoid bisection hazard let's fix this.

Note that there is a conflict at 'mm/rmap: allocate anon_vma_chain objects
unlocked when possible', please resolve it by just taking that patch and
dropping _everything_ from this one _including_ the trailing 'if (root) ...'
code.

The change here is purely to avoid bisection hazard.

Thanks, Lorenzo

----8<----
>From ef7c7118792b21a4d87b0bf2cee456f3bab92b24 Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Date: Wed, 14 Jan 2026 18:52:37 +0000
Subject: [PATCH] fix

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
---
 mm/rmap.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index 54ccf884d90a..0fcc831ce33d 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -432,7 +432,7 @@ int anon_vma_fork(struct vm_area_struct *vma, struct vm_area_struct *pvma)
 static void cleanup_partial_anon_vmas(struct vm_area_struct *vma)
 {
 	struct anon_vma_chain *avc, *next;
-	bool locked = false;
+	struct anon_vma *root = NULL;

 	/*
 	* We exclude everybody else from being able to modify anon_vma's
@@ -444,15 +444,18 @@ static void cleanup_partial_anon_vmas(struct vm_area_struct *vma)
 		struct anon_vma *anon_vma = avc->anon_vma;

 		/* All anon_vma's share the same root. */
-		if (!locked) {
-			anon_vma_lock_write(anon_vma);
-			locked = true;
+		if (!root) {
+			root = anon_vma->root;
+			anon_vma_lock_write(root);
 		}

 		anon_vma_interval_tree_remove(avc, &anon_vma->rb_root);
 		list_del(&avc->same_vma);
 		anon_vma_chain_free(avc);
 	}
+
+	if (root)
+		anon_vma_unlock_write(root);
 }

 /**
--
2.52.0