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 >
