Re: [PATCH v2 7/8] mm/rmap: allocate anon_vma_chain objects unlocked when possible

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

Hi Andrew,

Please apply the below fix-patch which addresses the issue raised by Suren
regarding the veracity of a comment around locks held.

Thanks, Lorenzo

----8<----
From dace24fb96c7fbf812e6cca2fb4aa0b6489ce8e3 Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Thu, 8 Jan 2026 18:49:07 +0000
Subject: [PATCH] fix comment

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

diff --git a/mm/rmap.c b/mm/rmap.c
index 8f4393546bce..576c7cde6464 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -297,8 +297,10 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
 	* are not updating the anon_vma rbtree nor are we changing
 	* anon_vma statistics.
 	*
-	* We hold the exclusive mmap write lock so there's no possibliity of
-	* the unlinked AVC's being observed yet.
+	* Either src, dst have the same mm for which we hold an exclusive mmap
+	* write lock, or we are forking and we hold it on src->vm_mm and dst is
+	* not yet accessible to other threads so there's no possibliity of the
+	* unlinked AVC's being observed yet.
 	*/
 	list_for_each_entry(pavc, &src->anon_vma_chain, same_vma) {
 		avc = anon_vma_chain_alloc(GFP_KERNEL);
--
2.52.0