Re: [PATCH v2 3/7] mm/mremap: introduce and use vma_remap_struct threaded state

[Vlastimil Babka <vbabka@suse.cz>]

On 3/6/25 11:33, Lorenzo Stoakes wrote:
> A number of mremap() calls both pass around and modify a large number of
> parameters, making the code less readable and often repeatedly having to
> determine things such as VMA, size delta, and more.
> 
> Avoid this by using the common pattern of passing a state object through
> the operation, updating it as we go.  We introduce the vma_remap_struct or
> 'VRM' for this purpose.

Small children here make such a 'VRM' sound when imitating a car.

> This also gives us the ability to accumulate further state through the
> operation that would otherwise require awkward and error-prone pointer
> passing.
> 
> We can also now trivially define helper functions that operate on a VRM
> object.
> 
> This pattern has proven itself to be very powerful when implemented for
> VMA merge, VMA unmapping and memory mapping operations, so it is
> battle-tested and functional.
> 
> We both introduce the data structure and use it, introducing helper
> functions as needed to make things readable, we move some state such as
> mmap lock and mlock() status to the VRM, we introduce a means of
> classifying the type of mremap() operation and de-duplicate the
> get_unmapped_area() lookup.
> 
> We also neatly thread userfaultfd state throughout the operation.
> 
> Note that there is further refactoring to be done, chiefly adjust
> move_vma() to accept a VRM parameter.  We defer this as there is
> pre-requisite work required to be able to do so which we will do in a
> subsequent patch.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

Reviewed-by: Vlastimil Babka <vbabka@suse.cz>