Re: [PATCH v3 1/9] mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one

From: Dev Jain

Date: Mon May 11 2026 - 04:25:09 EST




On 11/05/26 12:18 pm, David Hildenbrand (Arm) wrote:
> On 5/6/26 11:44, Dev Jain 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.
>
> Right, for hugetlb folios it should always stay at 1.
>
>>
>> Executing the above would imply a lazyfree folio is mapped by a mix of
>> present PTEs and device-exclusive PTEs.
>
> Why lazyfree? We use nr_pages also for
>
> folio_remove_rmap_ptes(folio, subpage, nr_pages, vma);
>
> and
>
> folio_put_refs(folio, nr_pages);
>
> Given that make_device_exclusive() operates on individual PTEs, wouldn't it be
> possible to trigger that?

At the point of this patch, batching is supported for lazyfree and file folios.
make_device_exclusive does not operate on file folios.

>
>