From: Jinoh Kang Subject: Re: [PATCH v3 07/13] loader: Don't clobber existing memory mappings when reserving addresses. Message-Id: <5e7b0a1e-4238-bbd8-b057-ac38114ed936@gmail.com> Date: Wed, 26 Jan 2022 11:54:56 +0900 In-Reply-To: <8bbcb555-b498-45d4-2150-692dea843ce9@gmail.com> References: <87y233yfx3.fsf@wine> <8bbcb555-b498-45d4-2150-692dea843ce9@gmail.com> On 1/26/22 11:52, Jinoh Kang wrote: > On 1/26/22 00:48, Alexandre Julliard wrote: >> Jinoh Kang writes: >> >>> Today, the preloader makes no attempt to avoid unmapping existing >>> memory mappings except the initial stack. This results in irrevocably >>> unmapping some useful preallocated memory areas, such as vDSO. >>> >>> Fix this by reading /proc/self/maps for existing VMAs, and splitting >>> mmap() calls to avoid erasing existing memory mappings. >> >> That defeats the purpose of using the preloader. > > The intention was to *incrementally* scrape memory areas for the reserved ranges, > relocating any critical areas (vDSO, stack, ...) along the way. > > It's also why this change is useless without the subsequent patches, > which calls map_reserve_preload_ranges again to actually fill out all > the gaps previously occupied by vDSO/stack. > >> The whole point is to make sure the specified ranges are available. > > It is. That's why I leave the preload_info ranges for Wine even though > I don't actually munmap() those pages. > >> Note that since you don't update the ranges info, the mappings will >> get erased by Wine later anyway. > > That was exactly what I intended: after jumping to ld.so, we no longer > need the code/data from preloader (except stack etc.), so we let Wine > unmap them. Also note that munmap()-ping preloader code and data from the preloader itself is unsafe, hence the commit message. This is why I'm deferring the actual unmapping to Wine itself. > > I'll make this clear in the next revision. > > (Note: the patch does update the ranges info when needed, particularly > when it fails to remap() vDSO/stack.) > -- Sincerely, Jinoh Kang