Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965215AbdIYQem (ORCPT ); Mon, 25 Sep 2017 12:34:42 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:29643 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965158AbdIYQek (ORCPT ); Mon, 25 Sep 2017 12:34:40 -0400 Subject: Re: [patch v2] mremap.2: Add description of old_size == 0 functionality To: "Michael Kerrisk (man-pages)" Cc: linux-man@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Jann Horn , Florian Weimer , Michal Hocko , Andrea Arcangeli , "Kirill A . Shutemov" , Vlastimil Babka , Anshuman Khandual References: <20170919214224.19561-1-mike.kravetz@oracle.com> <6fafdae8-4fea-c967-f5cd-d22c205608fa@gmail.com> From: Mike Kravetz Message-ID: <83b023da-e9f5-2957-981e-5b0e71e9bf1b@oracle.com> Date: Mon, 25 Sep 2017 09:33:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6fafdae8-4fea-c967-f5cd-d22c205608fa@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3300 Lines: 90 On 09/20/2017 12:25 AM, Michael Kerrisk (man-pages) wrote: > Hello Mike, > > On 09/19/2017 11:42 PM, Mike Kravetz wrote: >> v2: Fix incorrect wording noticed by Jann Horn. >> Remove deprecated and memfd_create discussion as suggested >> by Florian Weimer. >> >> Since at least the 2.6 time frame, mremap would create a new mapping >> of the same pages if 'old_size == 0'. It would also leave the original >> mapping. This was used to create a 'duplicate mapping'. >> >> A recent change was made to mremap so that an attempt to create a >> duplicate a private mapping will fail. >> >> Document the 'old_size == 0' behavior and new return code from >> below commit. >> >> commit dba58d3b8c5045ad89c1c95d33d01451e3964db7 >> Author: Mike Kravetz >> Date: Wed Sep 6 16:20:55 2017 -0700 >> >> mm/mremap: fail map duplication attempts for private mappings >> >> Signed-off-by: Mike Kravetz >> --- >> man2/mremap.2 | 21 ++++++++++++++++++++- >> 1 file changed, 20 insertions(+), 1 deletion(-) >> >> diff --git a/man2/mremap.2 b/man2/mremap.2 >> index 98643c640..235984a96 100644 >> --- a/man2/mremap.2 >> +++ b/man2/mremap.2 >> @@ -58,6 +58,20 @@ may be provided; see the description of >> .B MREMAP_FIXED >> below. >> .PP >> +If the value of \fIold_size\fP is zero, and \fIold_address\fP refers to >> +a shareable mapping (see >> +.BR mmap (2) >> +.BR MAP_SHARED ) >> +, then >> +.BR mremap () >> +will create a new mapping of the same pages. \fInew_size\fP >> +will be the size of the new mapping and the location of the new mapping >> +may be specified with \fInew_address\fP, see the description of >> +.B MREMAP_FIXED >> +below. If a new mapping is requested via this method, then the >> +.B MREMAP_MAYMOVE >> +flag must also be specified. >> +.PP >> In Linux the memory is divided into pages. >> A user process has (one or) >> several linear virtual memory segments. >> @@ -174,7 +188,12 @@ and >> or >> .B MREMAP_FIXED >> was specified without also specifying >> -.BR MREMAP_MAYMOVE . >> +.BR MREMAP_MAYMOVE ; >> +or \fIold_size\fP was zero and \fIold_address\fP does not refer to a >> +shareable mapping; >> +or \fIold_size\fP was zero and the >> +.BR MREMAP_MAYMOVE >> +flag was not specified. >> .TP >> .B ENOMEM >> The memory area cannot be expanded at the current virtual address, and the > > I've applied this, and added Reviewed-by tags for Florian and Jann. > But, I think it's also worth noting the older, now disallowed, behavior, > and why the behavior was changed. So I added a note in BUGS: > > BUGS > Before Linux 4.14, if old_size was zero and the mapping referred > to by old_address was a private mapping (mmap(2) MAP_PRIVATE), > mremap() created a new private mapping unrelated to the original > mapping. This behavior was unintended and probably unexpected in > user-space applications (since the intention of mremap() is to > create a new mapping based on the original mapping). Since Linux > 4.14, mremap() fails with the error EINVAL in this scenario. > > Does that seem okay? Sorry for the late reply Michael, I've been away for a few days. Yes, the above seems okay. Thanks for your help with this. -- Mike Kravetz