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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
