Re: [PATCH v4 03/12] mm/rmap: refactor some code around lazyfree folio unmapping

[Dev Jain]

On 09/06/26 7:50 pm, David Hildenbrand (Arm) wrote:
> On 5/26/26 08:36, Dev Jain wrote:
>> For lazyfree folio unmapping, after clearing the ptes we must abort the
>> operation if the folio got dirtied or it has unexpected references.
>>
>> Refactor this logic into a function which will return whether we need
>> to abort or not.
>>
>> If we abort, we restore the ptes and bail out of try_to_unmap_one.
>> Otherwise adjust the rss stats of the mm and jump to a label.
>>
>> Also rename that label from "discard" to "finish_unmap"; the former
>> is appropriate in the lazyfree context, but the code following the label
>> is executed for other successful unmap code paths too, so 'discard' does
>> not sound correct for them.
>>
>> Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
>> ---
>>  mm/rmap.c | 88 +++++++++++++++++++++++++++++++------------------------
>>  1 file changed, 50 insertions(+), 38 deletions(-)
>>
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index 06ab1158d4cd1..12bbee57f20da 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -2093,6 +2093,52 @@ static bool try_to_unmap_hugetlb_one(struct folio *folio,
>>  	return ret;
>>  }
>>  
>> +static inline bool ttu_lazyfree_folio(struct vm_area_struct *vma,
>> +		struct folio *folio)
> 
> Nitty, but I wonder whether we want to return an int with 0 vs. -EBUSY instead.
> 
> Reading "!ttu_lazyfree_folio" naturally makes me assume that this would be a
> success path (which it is not).

You have a point but if you don't have a strong opinion I'll prefer to keep as is.
-EBUSY won't be consumed by the callers anyways : )
> 
> 
> Apart from that LGTM.
>