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

[Oscar Salvador <osalvador@suse.de>]

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.

Let me add Lorenzo

> 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?

AFAIK we try to rollback as much as possible (vms_abort_munmap_vmas()),
but sometimes it is not possible.
For the problem here at hand, we could poke hugetlb to check whether it
has enough hugetlb pages, but that would be 1) racy and 2) we do not
want to special case hugetlb even more.

Hopefully Lorenzo can shed some light here.


-- 
Oscar Salvador
SUSE Labs