From: stsp <stsp2@yandex.ru>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Brian Geffon <bgeffon@google.com>,
Li Xinhai <lixinhai.lxh@gmail.com>,
Dmitry Safonov <0x7f454c46@gmail.com>,
linux-api@vger.kernel.org, linux-man@vger.kernel.org,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: MREMAP_DONTUNMAP corrupts initial mapping
Date: Fri, 31 Mar 2023 11:53:08 +0500 [thread overview]
Message-ID: <3a3422e5-8cd2-1a13-5eef-425383808396@yandex.ru> (raw)
In-Reply-To: <498d7a19-2b29-46ea-9c34-ec8fb7394e6c@lucifer.local>
Hi, thanks for info.
30.03.2023 23:42, Lorenzo Stoakes пишет:
> This seems to be a case of the documentation not quite being correct in the
> case of a MAP_PRIVATE file mapping, from the mremap man page discussing
> MREMAP_DONTUNMAP:-
Yes, it seems to be the case.
However, current semantic of MREMAP_DONTUNMAP
is unsatisfactory for many uses.
Have you considered adding more flags
to get things consistent?
For my use-case, at the very least 1 more
flag is needed to specify that in case of an
anonymous mapping I need the source
aliased not to zero-page but to destination
mapping, so that the source and dest do
match unless manually modified.
Another similar flag may be needed to
say that in case of a file-backed private
mapping source needs to be converted
to anonymous mapping, and if the first
flag is also specified, then again source
and dest would match. That can be used
in case the private file-backed mapping
was modified by hands.
Overall I need a set of flags that can
guarantee that MREMAP_DONTUNMAP
doesn't change the source data.
Can something like that be considered?
prev parent reply other threads:[~2023-03-31 7:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <aee53ac3-6d25-5009-7416-3f7c5fe1f989@yandex.ru>
[not found] ` <38c80313-ba1c-092c-ae31-f58fe6ffa82c@yandex.ru>
2023-03-30 18:42 ` MREMAP_DONTUNMAP corrupts initial mapping Lorenzo Stoakes
2023-03-31 6:53 ` stsp [this message]
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=3a3422e5-8cd2-1a13-5eef-425383808396@yandex.ru \
--to=stsp2@yandex.ru \
--cc=0x7f454c46@gmail.com \
--cc=bgeffon@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lixinhai.lxh@gmail.com \
--cc=lstoakes@gmail.com \
--cc=mtk.manpages@gmail.com \
/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