Re: [PATCH v6 24/39] mm/mlock: eliminate weird VMA_IO_BIT abuse and simplify

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] mm: TOCTOU race in try_to_migrate_one leaves folio pinned in mlock batch
--

commit cc15ce19ca95992151b61de2cedb165e4684ba4f
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>

mm/mlock: eliminate weird VMA_IO_BIT abuse and simplify

This commit simplifies mlock VMA flag handling by eliminating the use of
VMA_IO_BIT during mlock operations. It relies on VMA_LOCKONFAULT_BIT to mark
walks and updates mlock and unmap code paths to test appropriate VMA lock
flags instead.

> diff --git a/mm/rmap.c b/mm/rmap.c
> index 5332c52909be1..b4a4b3929044c 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c

[ ... ]

> @@ -2395,7 +2397,7 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
>  		}
>  finish_unmap:
>  		folio_remove_rmap_ptes(folio, page, nr_pages, vma);
> -		if (vma->vm_flags & VM_LOCKED)
> +		if (vma_test_any_mask(vma, VMA_LOCKED_MASK))
>  			mlock_drain_local();

[Severity: Low]
Can this double-check of VMA_LOCKED_MASK lead to a TOCTOU race?

folio_remove_rmap_ptes() calls munlock_vma_folio() internally, which checks
vma_test_any_mask(vma, VMA_LOCKED_MASK) to decide whether to queue the folio
in the local CPU's mlock batch.

Immediately after, try_to_unmap_one() re-evaluates the same mask to decide
whether to call mlock_drain_local(). A concurrent munlock() can clear the
VMA's locked flags exactly between these two checks.

If this happens, the folio is queued in the batch, but the local drain is
skipped. The local batch retains a reference to the folio, which permanently
pins it and can force best-effort migration like compaction to fail for this
page in a tight loop.

>  		folio_put_refs(folio, nr_pages);

[ ... ]

> @@ -2770,7 +2772,7 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
>  			hugetlb_remove_rmap(folio);
>  		else
>  			folio_remove_rmap_pte(folio, subpage, vma);
> -		if (vma->vm_flags & VM_LOCKED)
> +		if (vma_test_any_mask(vma, VMA_LOCKED_MASK))
>  			mlock_drain_local();

[Severity: Low]
Does this path suffer from the same TOCTOU vulnerability?

Like the unmap path above, if the VMA flags are cleared concurrently between
folio_remove_rmap_pte() and the check for mlock_drain_local(), the folio
could remain pinned in the local mlock batch.

>  		folio_put(folio);
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013-b4-mmap-prepare-vma-flag-sanify-v6-0-1aa3c9b139f9@kernel.org?part=24