[PATCH v3 07/13] loader: Don't clobber existing memory mappings when reserving addresses.

[Jinoh Kang]

On 1/26/22 11:52, Jinoh Kang wrote:
> On 1/26/22 00:48, Alexandre Julliard wrote:
>> Jinoh Kang <jinoh.kang.kr at gmail.com> 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