Re: [PATCH v2 1/9] mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one
From: Barry Song
Date: Fri Apr 10 2026 - 21:02:52 EST
On Fri, Apr 10, 2026 at 6:32 PM Dev Jain <dev.jain@xxxxxxx> wrote:
>
> Initialize nr_pages to 1 at the start of each loop iteration, like
> folio_referenced_one() does.
>
> Without this, nr_pages computed by a previous folio_unmap_pte_batch() call
> can be reused on a later iteration that does not run
> folio_unmap_pte_batch() again.
>
> I don’t think this is causing a bug today, but it is fragile.
>
> A real bug would require this sequence within the same try_to_unmap_one()
> call:
>
> 1. Hit the pte_present(pteval) branch and set nr_pages > 1.
> 2. Later hit the else branch and do pte_clear() for device-exclusive PTE,
> and execute rest of the code with nr_pages > 1.
>
> Executing the above would imply a lazyfree folio is mapped by a mix of
> present PTEs and device-exclusive PTEs.
>
> In practice, device-exclusive PTEs imply a GUP pin on the folio, and
> lazyfree unmapping aborts try_to_unmap_one() when it detects that
> condition. So today this likely does not manifest, but initializing
> nr_pages per-iteration is still the correct and safer behavior.
>
> Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
Acked-by: Barry Song <baohua@xxxxxxxxxx>