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 07:54:29PM +0100, Oscar Salvador wrote:
> 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.

Thanks, let me look at the OP...

>
>
> --
> Oscar Salvador
> SUSE Labs
>