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@xxxxxxxxxx> Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx>
