From: David Hildenbrand <david@redhat.com>
To: stsp <stsp2@yandex.ru>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: linux-mm@kvack.org, "Jakub Matěna" <matenajakub@gmail.com>,
"Hugh Dickins" <hughd@google.com>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>
Subject: Re: MREMAP_FIXED unmaps dest on error
Date: Mon, 3 Apr 2023 13:58:04 +0200 [thread overview]
Message-ID: <cba955a3-e41e-adce-954a-9a55d6d97065@redhat.com> (raw)
In-Reply-To: <18c36a78-4082-fab6-c7c9-69a249516803@yandex.ru>
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
parent reply other threads:[~2023-04-03 11:58 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <18c36a78-4082-fab6-c7c9-69a249516803@yandex.ru>]
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=cba955a3-e41e-adce-954a-9a55d6d97065@redhat.com \
--to=david@redhat.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matenajakub@gmail.com \
--cc=peterz@infradead.org \
--cc=stsp2@yandex.ru \
--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