Atomic mmap replacement

[Ken Brown]

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.

I hope I'm just missing something obvious.

Ken