Re: [PATCH v4 02/12] mm/rmap: Add try_to_unmap_hugetlb_one

[David Hildenbrand (Arm)]

On 6/23/26 10:40, Dev Jain wrote:
> 
> 
> On 09/06/26 7:46 pm, David Hildenbrand (Arm) wrote:
>> On 5/26/26 08:36, Dev Jain wrote:
>>> Simplify try_to_unmap_one by separating out the hugetlb parts into
>>> try_to_unmap_hugetlb_one.
>>>
>>> To understand the correctness of the refactoring, the following points
>>> are noted:
>>>
>>> 1. try_to_unmap() is called for hugetlb folios only when they are
>>>    hwpoisoned.
>>
>> Ack
>>
>>>
>>> 2. A hugetlb VMA cannot be mlocked.
>>
>> Ack
>>
>>>
>>> 3. The pvmw API sets pvmw.pte to the base of the hugetlb folio (pvmw.pmd
>>>    is NULL).
>>
>> Ack
>>
>>>
>>> 4. We won't ever process a softleaf entry that encodes a hugetlb folio;
>>>    hugetlb folios are never swapped out, migration entries will be skipped
>>>    (PVMW_MIGRATION not passed) and device-exclusive does not work for
>>>    hugetlb.
>>
>> Ack, we should always find present entries.
>>
>>>
>>> 5. uffd-wp bit is lost when converting pvmw.pte to hwpoison softleaf
>>>    (therefore no need to call pte_install_uffd_wp_if_needed after
>>>    clearing pvmw.pte)
>>
>> Are you sure? And if so, can you elaborate why + document?
> 
> If you see the current code, we construct pteval from the subpage, losing any
> bit state of the previous entry. Also it doesn't make sense anyways to keep
> uffd-wp for an hwpoisoned entry.

Ah, yes, makes sense. For some reason I confused hugetlb with hwpoison here ...
so yeah, this is good.

-- 
Cheers,

David