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. 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. Thanks, Brian On Mon, Feb 3, 2020 at 5:09 AM Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote: > > On Sun, Feb 02, 2020 at 05:17:53AM +0100, Brian Geffon wrote: > > On Wed, Jan 29, 2020 at 11:46 AM Kirill A. Shutemov > > <kirill@xxxxxxxxxxxxx> wrote: > > > Any better options for the flag name? (I have none) > > > > The other option is that it's broken up into two new flags the first > > MREMAP_MUSTMOVE which can be used regardless of whether or not you're > > leaving the original mapping mapped. This would do exactly what it > > describes: move the mapping to a new address with or without > > MREMAP_FIXED, this keeps consistency with MAYMOVE. > > > > The second flag would be the new MREMAP_DONTUNMAP flag which requires > > MREMAP_MUSTMOVE, again with or without MREMAP_FIXED. > > > > What are your thoughts on this? > > Sounds reasonable. > > MREMAP_DONTUNMAP doesn't really convey that you move pages to the new > mapping, but leave empty mapping behind. But I guess there's only so much > you can encode into the name. (Patch to the man page should do the rest) > > -- > Kirill A. Shutemov
