[PATCH v2] mm/rmap: synchronize lock and unlock target in anon_vma_clone

[PATCH v2] mm/rmap: synchronize lock and unlock target in anon_vma_clone

[Eric Kim]

Currently, in anon_vma_clone(), active_anon_vma is assigned from
src->anon_vma and is used when unlocking anon_vma after linking
new AVCs. However, the corresponding lock operation uses
src->anon_vma directly.

Use active_anon_vma consistently to make the lock/unlock pair explicit.

Signed-off-by: Eric Kim <seohyun.kim@outlook.kr>
---
v2:
- Clarify the commit message to explain that src->anon_vma and
  active_anon_vma refer to the same anon_vma.

mm/rmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/rmap.c b/mm/rmap.c
index 1c77d5dc06e9..f3fadfb69c7f 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -350,7 +350,7 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src,
 	 * Now link the anon_vma's back to the newly inserted AVCs.
 	 * Note that all anon_vma's share the same root.
 	 */
-	anon_vma_lock_write(src->anon_vma);
+	anon_vma_lock_write(active_anon_vma);
 	list_for_each_entry_reverse(avc, &dst->anon_vma_chain, same_vma) {
 		struct anon_vma *anon_vma = avc->anon_vma;
 
-- 
2.55.0

Re: [PATCH v2] mm/rmap: synchronize lock and unlock target in anon_vma_clone

[Rik van Riel]

On Mon, 2026-08-17 at 11:34 +0900, Eric Kim wrote:
> Currently, in anon_vma_clone(), active_anon_vma is assigned from
> src->anon_vma and is used when unlocking anon_vma after linking
> new AVCs. However, the corresponding lock operation uses
> src->anon_vma directly.
> 
> Use active_anon_vma consistently to make the lock/unlock pair
> explicit.
> 
> Signed-off-by: Eric Kim <seohyun.kim@outlook.kr>

Reviewed-by: Rik van Riel <riel@surriel.com>

-- 
All Rights Reversed.

Re: [PATCH v2] mm/rmap: synchronize lock and unlock target in anon_vma_clone

[Lance Yang]

On 2026/8/17 10:34, Eric Kim wrote:
> Currently, in anon_vma_clone(), active_anon_vma is assigned from
> src->anon_vma and is used when unlocking anon_vma after linking
> new AVCs. However, the corresponding lock operation uses
> src->anon_vma directly.
> 
> Use active_anon_vma consistently to make the lock/unlock pair explicit.
> 
> Signed-off-by: Eric Kim <seohyun.kim@outlook.kr>
> ---
> v2:
> - Clarify the commit message to explain that src->anon_vma and
>    active_anon_vma refer to the same anon_vma.

Just a heads-up... since only the commit message changed, the Reviewed-by
tags from v1 still apply, so please carry them over ...