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

[Jinoh Kang]

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.

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