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

[David Hildenbrand (Arm)]

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).


Apart from that LGTM.

-- 
Cheers,

David