Re: [patch v2] mremap.2: Add description of old_size == 0 functionality
From: Michael Kerrisk (man-pages) <hidden>
Date: 2017-09-20 07:25:48
Also in:
linux-man, linux-mm, lkml
Hello Mike, On 09/19/2017 11:42 PM, Mike Kravetz wrote:
quoted hunk ↗ jump to hunk
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 [off-list ref] Date: Wed Sep 6 16:20:55 2017 -0700 mm/mremap: fail map duplication attempts for private mappings Signed-off-by: Mike Kravetz <redacted> --- 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?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/