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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 6/23/26 10:42, Dev Jain wrote:
> 
> 
> 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@arm.com>
>>> ---
>>>  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 : )

Yeah, works for me, the "try_to" part implies what a bool return code means.

-- 
Cheers,

David