Rémi Bernon rbernon@codeweavers.com writes:
On 12/24/19 1:27 PM, Alexandre Julliard wrote:
Rémi Bernon rbernon@codeweavers.com writes:
We assumed that all mapped regions are known by Wine view tree, which is obviously not the case with external allocations. This could lead to memory corruption when find_free_area returns an expected free region which is already mapped. Using MAP_FIXED forces mmap to succeed and corrupts the mapping.
I have a feeling that this would be cleaner with a separate function, particularly since the algorithm to find free space in the system areas could be made smarter.
I'm not sure about what you mean by "smarter".
The original patches this whole zero bits thing is based upon were trying semi-random addresses to try to find free system areas, with a timeout [1], but I'm not completely convinced that it's better especially with the top_down flag to implement.
It could also read /proc/self/maps, making it not portable, I guess. Or maybe there's a way to enumerate mapped memory, including non-Wine, that I'm missing?
Or you just mean the search within an expected free area could do a bisection instead of iterating linearly?
Some kind of combination of these ideas, yes. But this should wait until after code freeze of course.