Re: [bug report?] unintuitive behavior when mapping over hugepage-backed PROT_NONE regions

["Jörn Engel" <joern@purestorage.com>]

On Thu, Feb 06, 2025 at 10:01:05AM +0100, Oscar Salvador wrote:
>
> That is because the above happens after __mmap_prepare(), which is
> responsible of unmapping any overlapping areas, is executed.
> I guess this is done this way because rolling back at this point would be
> quite tricky.

The big question (to me at least) is whether the current behavior is
correct or not.  I cannot find any documentation to that end, so maybe
this is a new question we have to answer for the first time.  So:

  In case of failure, should munmap() change the process address space?

As a user I would like the answer to be "no".  Partially because I was
personally surprised to see a change and surprises often result in bugs.
Partially because the specific change isn't even well-defined.  The size
of the unmapped region depends on the kernel configuration, you might
unmap a 2M-aligned chunk or a 1G-aligned chunk.

Are there contrary opinions out there?  Would it ever be useful to have
a failed mmap or munmap make changes to the process address space?

Jörn

--
I don't care what anything was designed to do,
I care about what it can do.
-- Gene Kranz