Re: [PATCH 12/15] mm: handle ANON_VMA_LAZY during migration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Critical] Dereferencing vma->vm_mm without protection leads to a use-after-free of the mm_struct.
- [High] Discarding the pointer returned by lock_vma_under_rcu() leads to a leaked per-VMA lock and unmatched unlock on the original VMA.
- [High] Migration unconditionally fails for unmapped anonymous folios because folio_trylock_get_anon_rmap() returns NULL for them.
- [High] Holding a dynamic number of anon_vma or VMA read locks concurrently during batch migration violates locking rules and overflows lockdep depth.
--

commit 18d8778974aea49701a86271f93dca924bc4ff06
Author: tao <tao.wangtao@honor.com>

mm: handle ANON_VMA_LAZY during migration

To ensure the atomicity of folio migration, introduce
folio_trylock_get_anon_rmap().

> diff --git a/mm/migrate.c b/mm/migrate.c
> index b397cdeab09a9..4abbfd1faea26 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
[ ... ]
> @@ -1287,26 +1300,17 @@ static int migrate_folio_unmap(new_folio_t get_new_folio,
[ ... ]
> -	if (folio_test_anon(src) && !folio_test_ksm(src))
> -		anon_rmap = folio_get_anon_rmap(src);
[ ... ]
> +	if (folio_test_anon(src) && !folio_test_ksm(src)) {
> +		anon_rmap = folio_trylock_get_anon_rmap(src);
> +		if (!anon_rmap_value(anon_rmap))
> +			goto out;
> +	}

[Severity: High]
Does this cause migration to unconditionally fail for unmapped anonymous
folios? For unmapped folios, folio_get_anon_vma() returns NULL because
folio_mapped() is false, which causes folio_trylock_get_anon_rmap() to
return ANON_RMAP_NULL. Before this change, the code ignored a NULL rmap
for unmapped folios and proceeded. With this goto out, any attempt to
migrate an unmapped anonymous folio might repeatedly fail with -EAGAIN.

[Severity: High]
Could this lead to holding a dynamic number of read locks concurrently
during batch migration? Because migrate_pages_batch() processes folios in
batches, it iterates and calls migrate_folio_unmap() to acquire the lock
for every folio before it begins calling migrate_folio_move() to release
them.

Holding these locks concurrently across an entire batch could easily exceed
lockdep's MAX_LOCK_DEPTH (48) and cause severe contention or stall writers
on those VMAs during long-latency operations like TLB flushing.

[ ... ]
> diff --git a/mm/rmap.c b/mm/rmap.c
> index cb104310cdc9b..bd5587735ee06 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1223,6 +1223,46 @@ anon_rmap_t folio_lock_anon_rmap_read(const struct folio *folio,
>  	return anon_vma ? anon_vma_to_anon_rmap(anon_vma) : ANON_RMAP_NULL;
>  }
>  
> +anon_rmap_t folio_trylock_get_anon_rmap(const struct folio *folio)
> +{
> +	struct anon_vma *anon_vma;
> +	struct vm_area_struct *vma;
> +
> +	if (folio_test_anon_vma_lazy(folio)) {
> +		vma = folio_get_anon_vma_lazy(folio);
> +		if (vma && !lock_vma_under_rcu(vma->vm_mm, vma->vm_start)) {

[Severity: Critical]
Is it safe to dereference vma->vm_mm here without protection? While the VMA
object itself might be protected from being freed, a VMA does not pin its
associated mm_struct. If the process has exited, the mm_struct could be
freed via free_mm().

Passing a dangling vma->vm_mm pointer to lock_vma_under_rcu(), which
attempts to walk the maple tree, could result in a use-after-free.

[Severity: High]
Does this discard the pointer returned by lock_vma_under_rcu() and leak the
per-VMA lock?

lock_vma_under_rcu() returns a pointer to the locked VMA if successful.
The condition implicitly casts this pointer to a boolean and discards it.
If the lock succeeds, the code proceeds to return the original vma pointer
instead of the locked one, leaving the successfully locked VMA permanently
locked.

Later, anon_rmap_unlock_put() would call vma_end_read() on the original
vma pointer, which was never explicitly locked.

> +			vma_put(vma);
> +			vma = NULL;
> +		}
> +		if (vma)
> +			return vma_to_anon_rmap(vma);
> +	}
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527110147.17815-1-tao.wangtao@honor.com?part=12