Re: [PATCH v6 1/2] mm: Add MREMAP_DONTUNMAP to mremap().

From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Brian Geffon <bgeffon@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	Linux API <linux-api@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Will Deacon <will@kernel.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Sonny Rao <sonnyrao@google.com>, Minchan Kim <minchan@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Yu Zhao <yuzhao@google.com>, Jesse Barnes <jsbarnes@google.com>,
	Florian Weimer <fweimer@redhat.com>
Subject: Re: [PATCH v6 1/2] mm: Add MREMAP_DONTUNMAP to mremap().
Date: Fri, 21 Feb 2020 15:23:47 +0300	[thread overview]
Message-ID: <20200221122347.vlw6r7felchtcxgq@box> (raw)
In-Reply-To: <CADyq12y2uJh2ROBajA1D5H6OLEyFrKKEXH=yQC-8ELF0+UiNzw@mail.gmail.com>

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