On Mon, Mar 10, 2025 at 03:11:01PM +0100, Vlastimil Babka wrote: > On 3/6/25 11:34, Lorenzo Stoakes wrote: > > Update move_vma() to use the threaded VRM object, de-duplicate code and > > separate into smaller functions to aid readability and debug-ability. > > > > This in turn allows further simplification of expand_vma() as we can > > simply thread VRM through the function. > > > > We also take the opportunity to abstract the account charging page count > > into the VRM in order that we can correctly thread this through the > > operation. > > > > We additionally do the same for tracking mm statistics - exec_vm, > > stack_vm, data_vm, and locked_vm. > > > > As part of this change, we slightly modify when locked pages statistics > > are counted for in mm_struct statistics. However this should cause no > > issues, as there is no chance of underflow, nor will any rlimit failures > > occur as a result. > > > > This is an intermediate step before a further refactoring of move_vma() in > > order to aid review. > > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > > Reviewed-by: Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> > > Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx> > > Can't wait what the bots report what I've missed in this one. > Thanks :) To be fair the other one was an extremely weird edge case where a user 'remaps' a region of a VMA of length 0 onto itself expanding the length 0 mapping to the length of the VMA, i.e. a weird way of doing an unmap. With that caught, and heavy testing of _real world_ usage of this series done locally, I think we _should_ be ok... obviously bots have been hammering with no issues other than aforementioned crazy case.
