[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3a3422e5-8cd2-1a13-5eef-425383808396@yandex.ru>
Date: Fri, 31 Mar 2023 11:53:08 +0500
From: stsp <stsp2@...dex.ru>
To: Lorenzo Stoakes <lstoakes@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mm@...ck.org, Brian Geffon <bgeffon@...gle.com>,
Li Xinhai <lixinhai.lxh@...il.com>,
Dmitry Safonov <0x7f454c46@...il.com>,
linux-api@...r.kernel.org, linux-man@...r.kernel.org,
Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: MREMAP_DONTUNMAP corrupts initial mapping
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?
Powered by blists - more mailing lists