Broken autoconf mmap test

Larry Hall (Cygwin Developers)
Thu Mar 24 19:13:00 GMT 2011

On 3/24/2011 2:24 PM, Corinna Vinschen wrote:
> On Mar 24 13:52, Christopher Faylor wrote:
>> On Thu, Mar 24, 2011 at 06:40:36PM +0100, Corinna Vinschen wrote:
>>> On Mar 24 12:44, Christopher Faylor wrote:
>>>> On Thu, Mar 24, 2011 at 10:23:57AM -0600, Eric Blake wrote:
>>>>> On 03/24/2011 10:21 AM, Christopher Faylor wrote:
>>>>>>> - In all three possible solutions above: What if the original file
>>>>>>>   handle used in the mmap call has been closed and the file permissions
>>>>>>>   have been changed in the meantime so that the process does not have
>>>>>>>   write permissions anymore?
>>>>>> - Isn't it going to be really slow?  I guess if it only happens once
>>>>>> per page it won't be that bad but still: ouch.
>>> There is a good chance that it's going to be slower.  I'm not sure if
>>> loading the file into the anonymous mapping is a problem since that
>>> would have to be done under the hood as well, if the mapping is a file
>>> mapping.  For the first write to each page you have a hit of a couple of
>>> cycles to change the page protection.  When writing back the changes you
>>> have to open the file, scan the pages and write back the changed ones.
>>> Opening the handle could be quite a hit, writing the changes back would
>>> be basically the same as the OS has to do as well.  However, while the
>>> OS can do so in the background whenever it sees fit, Cygwin couldn't.
>>>>> And if I'm understanding correctly, it only needs to happen for the one
>>>>> page at the end of the file; all earlier 64k chunks of the file can be
>>>>> mapped normally, if you can guarantee that the normal mappings are
>>>>> adjacent with the one special mapping.
>>>> Ah.  So that would make it like a stack guard page then.
>>> Uh, no.  This is an anonymous mapping, ok?  So there's no connection
>>> to the file which has been mapped.  So the mechanism would have to
>>> cover the entire mapping.  It would kind of having all pages set to
>>> be guard pages, but you can't really use guard pages since they have
>>> a hit for writing *and* reading.
>> Ok.  So I had it right to begin with.  This is like a guard page insofar
>> as you see an exception the first time you hit a page but it's not really
>> a "guard page" in any other sense.
> Yep.  A real guard page would not be very useful in this scenario.
> The exception handler would have to restore the PAGE_GUARD protection
> for every read access.  That would really be an enormous hit.
>> I really hate that we have to go to such lengths to implement sensical
>> behavior.*
> That's the question.  Do we have to?  I wrote my original mail to have
> one potential solution to this problem in the records in the first
> place.  The other hope was that somebody has some better idea I just
> don't see.
> While the method I called the hard way is certainly implementable
> somehow, I don't think it has any real chance.  It's much to complicated
> to get right.  And then again, all this uproar for a border case
> which is in theory not used by any sensible application?  It's nice that
> the autoconf test tests the POSIX requirement that the page reminder is
> filled with 0 bytes, but, is that really necessary?  What for?
> And, is the autoconf test perhaps the only client for this solution
> since no sensible application will read and write bytes beyond EOF?  If
> so, it's kind of sad that an autoconf test will result in lots of
> application not using mmap, even though none of them actually uses the
> map beyond EOF.
> So, whatever we do in Cygwin's mmap, it's either rock or hard place,
> as far as I can see

I do think it's worthwhile to examine the "why" before making changes here.
If the main (only?) gain here is to appease autoconf, is there a way we can
"cheat" at this?  Getting autoconf'd packages to use mmap is a good thing
but it does sound to me like it needs to be way easier for Cygwin to do
this right, we need a specific work-around to target autoconf checks, or we
shouldn't bother (for now).


More information about the Cygwin-developers mailing list