Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3a3422e5-8cd2-1a13-5eef-425383808396@yandex.ru>
Date:   Fri, 31 Mar 2023 11:53:08 +0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: MREMAP_DONTUNMAP corrupts initial mapping
Content-Language: en-US
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>
References: <aee53ac3-6d25-5009-7416-3f7c5fe1f989@yandex.ru>
 <38c80313-ba1c-092c-ae31-f58fe6ffa82c@yandex.ru>
 <498d7a19-2b29-46ea-9c34-ec8fb7394e6c@lucifer.local>
From:   stsp <stsp2@yandex.ru>
In-Reply-To: <498d7a19-2b29-46ea-9c34-ec8fb7394e6c@lucifer.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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?