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