From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Bert Karwatzki <spasswolf@web.de>,
Jiri Olsa <olsajiri@gmail.com>, Kees Cook <kees@kernel.org>,
Mark Brown <broonie@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Paul Moore <paul@paul-moore.com>,
Sidhartha Kumar <sidhartha.kumar@oracle.com>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>
Subject: Re: MAP_FIXED leaving holes on failure is very difficult to recover from and can even be a security hole
Date: Thu, 5 Nov 2026 15:11:48 +0000 [thread overview]
Message-ID: <auyXeApQlV_CMQDm@gremlin> (raw)
In-Reply-To: <8b45a161-101f-4f28-9b7a-c7c8b8a29f90@gmail.com>
[ please check kernel mails in MAINTAINERS - my and Liam's at least were
incorrect, which makes it easy to miss. Fixed those up. ]
Thanks for the report.
In general linux system calls do not guarantee compound operation
atomicity, and any assumption based on that is incorrect. If you see an
error - the operation failed, perhaps partially.
Further, a failed MAP_FIXED leaving gaps was the case for most of the
history of linux. Avoiding that is infeasible.
I advise you to review the NOTES section
https://man7.org/linux/man-pages/man2/mmap.2.html on MAP_FIXED - your
suggested use of it is not recommended.
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-11-05 15:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 0:56 MAP_FIXED leaving holes on failure is very difficult to recover from and can even be a security hole Demi Marie Obenour
2026-11-05 15:11 ` Lorenzo Stoakes (ARM) [this message]
2026-11-05 23:59 ` Demi Marie Obenour
2026-11-06 7:58 ` Vlastimil Babka (SUSE)
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=auyXeApQlV_CMQDm@gremlin \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=demiobenour@gmail.com \
--cc=kees@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=olsajiri@gmail.com \
--cc=paul@paul-moore.com \
--cc=paulmck@kernel.org \
--cc=sidhartha.kumar@oracle.com \
--cc=spasswolf@web.de \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.