On Fri, Feb 07, 2020 at 12:42:15PM -0800, Brian Geffon wrote: > Hi Kirill, > I started a new thread https://lkml.org/lkml/2020/2/7/640 for my v4 > patch. But I wanted to quickly address your comments. Regarding the > concern around the rmap, no changes actually need to be made. If we > were to unlink_anon_vma(vma) and then set vma->anon_vma = NULL, that > would be fine but then as soon as there was a fault the same anon_vma > would be attached since it's a private anonymous mapping. So there is > really nothing to do regarding the rmap. Okay. My worry was that we create a new VMA with the same anon_vma *and* vm_pgoff, but I just realized we can do the same with the current mremap(2) plus following mmap(2) in the old place. So it's not regression. I guess we are fine here. > I considered the two flag approach but since I could not come up with > a concrete use case of MREMAP_MUSTMOVE I decided to just leave the > single MREMAP_DONTUNMAP flag, the two flag approach would be only for > clarifying the operations so I'm not sure it's worth it. (Still trying > to come up with a better name). But I've attached a man page diff to > the latest patch. At least it doesn't have 'FIXED' semantics forced on user. It's fine with me. -- Kirill A. Shutemov
