This is the mail archive of the cygwin-developers mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Broken autoconf mmap test

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


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]