[CC expanded to include a few people who tested/acked/reviewed the original kernel patch.] Hello Brian, Thanks for this patch. I've applied it, and done quite a bit of editing. Could you please take a look at the version in Git, and let me know if I made any bad changes to your text. In addition, I have one or two questions below. On 4/15/20 6:49 PM, Brian Geffon wrote: > Signed-off-by: Brian Geffon <bgeffon@xxxxxxxxxx> > --- > man2/mremap.2 | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/man2/mremap.2 b/man2/mremap.2 > index d73fb64fa..ff5939ff1 100644 > --- a/man2/mremap.2 > +++ b/man2/mremap.2 > @@ -129,6 +129,22 @@ If > is specified, then > .B MREMAP_MAYMOVE > must also be specified. > +.TP > +.BR MREMAP_DONTUNMAP " (since Linux 5.7)" > +.\" commit e346b3813067d4b17383f975f197a9aa28a3b077 > +This flag which must be used in conjunction with > +.B MREMAP_MAYMOVE > +remaps a mapping to a new address and it does not unmap the mapping at > +.BR old_address . > +This flag can only be used with private anonymous mappings. > +Any access to the range specified at > +.BR old_address > +after completion will result in an anonymous page fault. > +The anonymous page fault will be handled by a > +.BR userfaultfd (2) > +if the range was previously registered on the mapping specified by > +.BR old_address . > +Otherwise, it will be zero filled by the kernel. > .PP > If the memory segment specified by > .I old_address > @@ -176,6 +192,8 @@ a value other than > .B MREMAP_MAYMOVE > or > .B MREMAP_FIXED > +or > +.B MREMAP_DONTUNMAP > was specified in > .IR flags ; > .IP * > @@ -197,9 +215,22 @@ and > .IR old_size ; > .IP * > .B MREMAP_FIXED > +or > +.B MREMAP_DONTUNMAP > was specified without also specifying > .BR MREMAP_MAYMOVE ; > .IP * > +.B MREMAP_DONTUNMAP > +was specified with and > +.BR old_address > +that was not private anonymous; > +.IP * > +.B MREMAP_DONTUNMAP > +was specified and > +.BR old_size > +was not equal to > +.BR new_size ; > +.IP * > \fIold_size\fP was zero and \fIold_address\fP does not refer to a > shareable mapping (but see BUGS); > .IP * > @@ -209,10 +240,20 @@ flag was not specified. > .RE > .TP > .B ENOMEM > +Not enough memory was available to complete the operation. > +Possible causes are: > +.RS > +.IP * 3 > The memory area cannot be expanded at the current virtual address, and the > .B MREMAP_MAYMOVE > flag is not set in \fIflags\fP. > Or, there is not enough (virtual) memory available. > +.IP * > +.B MREMAP_DONTUNMAP > +was used causing a new mapping to be created that would exceed the > +(virtual) memory available. > +Or, it would exceed the maximum number of allowed mappings. > +.RE > .SH CONFORMING TO > This call is Linux-specific, and should not be used in programs > intended to be portable. > @@ -238,6 +279,14 @@ call will make a best effort to populate the new area but will not fail > with > .B ENOMEM > if the area cannot be populated. > +.PP > +The > +.BR MREMAP_DONTUNMAP > +flag may be used to atomically move a mapping while leaving the source > +mapped. You write "move", but would it not be more correcrt to say something like "duplicate"? > +Possible applications for this behavior might be garbage collection or Can you elaborate the garbage collection use case a little, please? > +non-cooperative > +.BR userfaultfd (2) . What is noncooperative userfaultfd(2)? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
