From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Brian Geffon <bgeffon@google.com>
Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org,
Sonny Rao <sonnyrao@google.com>,
Jesse Barnes <jsbarnes@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Minchan Kim <minchan@kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Lokesh Gidra <lokeshgidra@google.com>
Subject: Re: [PATCH v2] mremap.2: Add information for MREMAP_DONTUNMAP.
Date: Thu, 16 Apr 2020 09:07:08 +0200 [thread overview]
Message-ID: <092fc948-4adb-cda8-f525-7d16a85674e7@gmail.com> (raw)
In-Reply-To: <20200415164949.44562-1-bgeffon@google.com>
[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@google.com>
> ---
> 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/
next prev parent reply other threads:[~2020-04-16 7:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 16:49 [PATCH v2] mremap.2: Add information for MREMAP_DONTUNMAP Brian Geffon
2020-04-16 7:07 ` Michael Kerrisk (man-pages) [this message]
2020-04-17 3:01 ` Brian Geffon
2020-04-22 0:15 ` Lokesh Gidra
2020-04-22 12:08 ` Michael Kerrisk (man-pages)
2020-04-22 12:05 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=092fc948-4adb-cda8-f525-7d16a85674e7@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=bgeffon@google.com \
--cc=jsbarnes@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-man@vger.kernel.org \
--cc=lokeshgidra@google.com \
--cc=minchan@kernel.org \
--cc=sonnyrao@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).