[PATCH 3/4] ntdll: Force virtual memory allocation order.

[Ken Thomases]

On Aug 19, 2020, at 10:06 AM, Paul Gofman <pgofman at codeweavers.com> wrote:
> 
> On 8/19/20 17:56, Gabriel Ivăncescu wrote:
>> Sorry for the late reply, but I was a bit interested in this patch (which doesn't seem to have gone anywhere yet?).
>> 
>> I think this should also fix bug 38668.
> 
> I am frankly not quite sure how to move forward with this. I've got a comment from Rémi who rightfully considered the change to big for a one time change. While I do agree with that in principle, I don't see the way how to simplify the change without introducing a more complicated and ugly state in between (I have wrote some more details in the previous e-mail).
> 
> I also received a comment from Alexandre in the chat that he is sceptical about the idea because it is getting too complicated.
> 
> For now I don't see any other substantially different and good way to solve the bunch of related bugs. Besides the referenced bugs, it is also known to affect Mortal Kombat 11 and Star Wars: Battlefron II for now.
> 
> So I am not sure how to proceed from here. Should we just leave these bugs, or is there some direction of how to do it simpler which I am missing, or should I maybe try harder to structure the code in some more clear way?

I haven't paid really close attention.  Is this just about doing bottom-up allocation?  For the non-MAP_FIXED case, if you supply a non-zero address to mmap(), don't most systems take that as a hint and try to allocate there?  If they can't, do they then search from there for the closest available free region?

macOS behaves like that.  Not sure about other platforms.  (Then again, macOS has the Mach APIs which allow enumerating the free/allocated regions pretty directly.  See the Mac-specific implementation of reserve_area() in libs/wine/mmap.c.)

-Ken