Atomic mmap replacement

[Ken Brown]

On 12/18/2024 9:28 AM, Corinna Vinschen via Cygwin wrote:
> Hi Ken,
> 
> On Dec 17 15:23, Ken Brown via Cygwin wrote:
>> Hi Corinna,
>>
>> On 12/17/2024 11:38 AM, Corinna Vinschen via Cygwin wrote:
>>> Ideally a separate patch.  If you see a chance to send it to cygwin-patches
>>> this week, we can even merge it into 3.5.5, which I'm planning to release
>>> end of this week (after that --> vacation :)))
>> That should be no problem.  By the way, I think I found a second bug.
>> Shouldn't mmap:649 be
>>
>> (*)  if (u_addr > (caddr_t) addr || u_len < len
>>
>> instead of
>>
>> (**)  if (u_addr > (caddr_t) addr || u_addr + len < (caddr_t) addr + len
>>
>> ?
>>
>> If the first condition in (**) fails, then u_addr == addr, so the second
>> condition is automatically false.  But what we want to be testing at this
>> point is whether the matched region is big enough, as in (*).  Or am I
>> confused?
> 
> u_addr could be < addr.  We have two areas, the free area in u_addr and
> u_len, and the requested area in addr and len.
> 
> So we have to check that addr is >= u_addr and addr + len is <= u_len:
> 
>    |----------------------------------------------------|
>   u_addr                                           u_addr + u_len
> 
>             |--------------------|
>            addr             addr + len
> 
> Make sense?
No, I'm still confused.  I thought that the interval determined by 
u_addr and u_len was the intersection of the requested interval and the 
whole interval of the mmap_record; this implies u_addr >= addr.  Back in 
the definition of mmap_record::match, we set low = max (addr, 
get_address ()), and then on success we set m_addr = low.  Doesn't that 
imply m_addr >= addr?  Sorry if I'm just being dense.

Ken