Atomic mmap replacement

[Ken Brown]

On 12/18/2024 5:24 PM, Ken Brown via Cygwin wrote:
> On 12/18/2024 1:35 PM, Corinna Vinschen via Cygwin wrote:
>> On Dec 18 10:45, Ken Brown via Cygwin wrote:
>>> 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_add = low.  Doesn't that imply m_addr >= 
>>> addr?
>>> Sorry if I'm just being dense.
>>
>> Apologies, I didn't check mmap_record::match().  You're right of course.
>> So, yeah, just go ahead.
> I think I'm seeing a similar confusion in 
> mmap_is_attached_or_noreserve().  I'm tired now and am having trouble 
> sorting out exactly what that function is doing.  But the definition of 
> commit_len looks suspicious to me.  We know from above that start_addr 
> <= u_addr.  So the quantity we're subtracting from u_len is actually <= 
> 0.  That can't be what's intended.  Then in the call to VirtualAlloc, 
> we're allocating starting at start_addr.  But how do we know that 
> start_addr is in the noreserve region mapped by rec?  All we know is 
> that the interval from u_addr to u_addr + u_len is in that region.

The only thing I can come up with immediately is that we should sort the 
list of mmap_records in order of their starting addresses.  Then if 
start_addr == u_addr, we commit u_len bytes, otherwise we fail.

> I hope I'm just missing something obvious.
Still hoping...

Ken