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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Thu, Feb 06, 2025 at 10:11:30AM -0800, Jörn Engel wrote:
> 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?
>

Yes :)

I will reply on the top thread with everyone cc'd though.


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