On Thu, Feb 20, 2020 at 03:55:53PM -0800, Brian Geffon wrote: > Hi Kirill, > > > I have hard time understanding the case when new_len != old_len. > > > > Correct me if I'm wrong, but looks like that you change the size of old > > mapping to be the new_len and then create a new of the same new_len. > > > > This doesn't look right to me. > > > > In my opinion, MREMAP_DONTUNMAP has to leave the old mapping intact. And > > create the new mapping adjusted to the new_len. > > > > Other option is to force new_len == old_len if MREMAP_DONTUNMAP is > > specified. It would simplify the implementation. And I don't see why > > anybody would really want anything else. > > I had been approaching this as, "do what mremap would have done in > this situation except skip the last step." Meaning, whatever the final > state of the old mapping was MREMAP_DONTUNMAP meant that you should > just not do the unmap operation on the old mapping at the end. But I > understand why it's confusing, especially when in the case of the VMA > growing you're left with the old vma of size old_len and the new_vma > of size new_len but only containing old_len worth of pages. > Personally, I don't think this is a problem having that behavior > because it can be documented and it just adds a small amount of > flexibility. > > Nonetheless, I agree with you and I also cannot come up with a > situation where you'd actually want to do this so I'm willing to > restrict it to old_len == new_len and return -EINVAL if not, it > simplifies it a bit and accounting becomes a easier because the > outcome is always the same two mappings of size old_len and the size > of the locked_vm never changes. We can always allow the resize > operation later if there becomes a need. If everyone is okay with this > restriction I can send a new patch. If anyone would want to chagne size it can be archived by followup mremap() operations. There's no need in one-shot operation. -- Kirill A. Shutemov
