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 >
