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: <cba955a3-e41e-adce-954a-9a55d6d97065@redhat.com>
Date:   Mon, 3 Apr 2023 13:58:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.1
Content-Language: en-US
To:     stsp <stsp2@yandex.ru>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc:     linux-mm@kvack.org,
        =?UTF-8?Q?Jakub_Mat=c4=9bna?= <matenajakub@gmail.com>,
        Hugh Dickins <hughd@google.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>
References: <18c36a78-4082-fab6-c7c9-69a249516803@yandex.ru>
From:   David Hildenbrand <david@redhat.com>
Organization: Red Hat
Subject: Re: MREMAP_FIXED unmaps dest on error
In-Reply-To: <18c36a78-4082-fab6-c7c9-69a249516803@yandex.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 30.03.23 17:48, stsp wrote:
> Hello.
> 
> The attached test-case demonstrates a
> bug in mremap(). If MREMAP_FIXED is used
> over an existing mapping and mremap() fails,
> destination area gets unmapped.
> AFAIK the failed syscall should have no
> observable effects.

I remember that holds for various mapping-related syscalls: if something 
goes wrong, the end result is not guaranteed to be what we had before 
the syscall.

For example, if you use mmap(MAP_FIXED) to replace part of an exiting 
mapping, we first munmap what's there and then try to mmap the new 
mapping. If something goes wrong while doing that, we cannot simple undo 
what we already did.

Long story short: the semantics of these syscalls has never been to 
leave the system in the state as it was before in case anything goes wrong.


As another example, if you do an mprotect() that covers multiple VMAS, 
and there is an issue with the last VMA, all but the last VMA will have 
their permissions changed.

-- 
Thanks,

David / dhildenb