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

[Vlastimil Babka <vbabka@suse.cz>]

On 2/6/25 19:11, 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?
> 
> Jörn
> 
> --
> I don't care what anything was designed to do,
> I care about what it can do.

Incidentally, a similar thing may apply to existing userspace application
that learned to expect the unmap on failure, and if we now fix the kernel to
stop doing that, that application might break. However in this case it's
probably very unlikely such application exists, so we might try and see if
anyone complains...

> -- Gene Kranz
>