On 1/27/25 16:50, Lorenzo Stoakes wrote: > The current VMA merge mechanism contains a number of confusing mechanisms > around removal of VMAs on merge and the shrinking of the VMA adjacent to > vma->target in the case of merges which result in a partial merge with that > adjacent VMA. > > Since we now have a STABLE set of VMAs - prev, middle, next - we are now > able to have the caller of commit_merge() explicitly tell us which VMAs > need deleting, using newly introduced internal VMA merge flags. > > Doing so allows us to embed this state within the VMG and remove the > confusing remove, remove2 parameters from commit_merge(). > > We additionally are able to eliminate the highly confusing and misleading > 'expanded' parameter - a parameter that in reality refers to whether or not > the return VMA is the target one or the one immediately adjacent. > > We can infer which is the case from whether or not the adj_start parameter > is negative. This also allows us to simplify further logic around iterator > configuration and VMA iterator stores. > > Doing so means we can also eliminate the adjust parameter, as we are able > to infer which VMA ought to be adjusted from adj_start - a positive value > implies we adjust the start of 'middle', a negative one implies we adjust > the start of 'next'. > > We are then able to have commit_merge() explicitly return the target VMA, > or NULL on inability to pre-allocate memory. Errors were previously > filtered so behaviour does not change. > > This patch has no change in functional behaviour. > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> Some of the parts would be quite a hack for a final state of things, but I understand it's a intermediate step for review purposes. Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx>
