On Mon, Mar 10, 2025 at 08:50:36PM +0000, 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. > > 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@xxxxxxxxxx> > Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx> > --- Looks good to me, Reviewed-by: Harry Yoo <harry.yoo@xxxxxxxxxx> -- Cheers, Harry
