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

[PATCH v4] 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.

Although they are actually the same thing, use active_anon_vma
consistently to make the lock/unlock pair explicit.

Signed-off-by: Eric Kim <seohyun.kim@outlook.kr>
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Lance Yang <lance.yang@linux.dev>
Reviewed-by: Rik van Riel <riel@surriel.com>
Reviewed-by: Barry Song <baohua@kernel.org>
---
v2:
- Clarify the commit message to explain that src->anon_vma and
  active_anon_vma refer to the same anon_vma.
v3:
- Carry over review tags from v2.
v4:
- Clarify ctive_anon_vma and src->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 v4] mm/rmap: synchronize lock and unlock target in anon_vma_clone

[Lorenzo Stoakes (ARM)]

On Mon, Aug 17, 2026 at 02:25:11PM +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.
>
> Although they are actually the same thing, use active_anon_vma
> consistently to make the lock/unlock pair explicit.

Thanks! LGTM

(Your email bounced for me last time so not sure you'll see this :)

>
> Signed-off-by: Eric Kim <seohyun.kim@outlook.kr>
> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Rik van Riel <riel@surriel.com>
> Reviewed-by: Barry Song <baohua@kernel.org>
> ---
> v2:
> - Clarify the commit message to explain that src->anon_vma and
>   active_anon_vma refer to the same anon_vma.
> v3:
> - Carry over review tags from v2.
> v4:
> - Clarify ctive_anon_vma and src->anon_vma refer to the same
>   anon_vma.

Extremely petty nit - and you don't have to do anything this is just for the
future:

- Prefer a reverse order, so latest revision at the top.
- Nice to have lore links to previous revisions.

:)

>
> 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
>

--
Cheers, Lorenzo

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

[Lorenzo Stoakes (ARM)]

On Mon, Aug 17, 2026 at 08:43:30AM +0100, Lorenzo Stoakes (ARM) wrote:
> On Mon, Aug 17, 2026 at 02:25:11PM +0900, Eric Kim wrote:
> > ---
> > v2:
> > - Clarify the commit message to explain that src->anon_vma and
> >   active_anon_vma refer to the same anon_vma.
> > v3:
> > - Carry over review tags from v2.
> > v4:
> > - Clarify ctive_anon_vma and src->anon_vma refer to the same
> >   anon_vma.
>
> Extremely petty nit - and you don't have to do anything this is just for the
> future:
>
> - Prefer a reverse order, so latest revision at the top.
> - Nice to have lore links to previous revisions.

Oh and also - nice to attribute the changes to the person who requested them,
e.g. 'Clarify xxx as per Barry Song', etc. thanks! :)

--
Cheers, Lorenzo