X-Spam-Check-By: sourceware.org
Date: Wed, 10 Jan 2007 17:12:41 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.0 CVS mmap failure
Message-ID: <20070110161241.GM23638@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <Pine DOT CYG DOT 4 DOT 58 DOT 0701041715140 DOT 3520 AT PC1163-8460-XP DOT flightsafety DOT com> <20070105095752 DOT GB28768 AT calimero DOT vinschen DOT de> <Pine DOT CYG DOT 4 DOT 58 DOT 0701050959060 DOT 2704 AT PC1163-8460-XP DOT flightsafety DOT com> <Pine DOT CYG DOT 4 DOT 58 DOT 0701051054010 DOT 280 AT PC1163-8460-XP DOT flightsafety DOT com> <Pine DOT CYG DOT 4 DOT 58 DOT 0701051144030 DOT 2880 AT PC1163-8460-XP DOT flightsafety DOT com> <20070105182234 DOT GC12776 AT calimero DOT vinschen DOT de> <Pine DOT CYG DOT 4 DOT 58 DOT 0701051237090 DOT 2880 AT PC1163-8460-XP DOT flightsafety DOT com> <20070105192302 DOT GD12776 AT calimero DOT vinschen DOT de> <20070110095345 DOT GL23638 AT calimero DOT vinschen DOT de> <Pine DOT CYG DOT 4 DOT 58 DOT 0701100903410 DOT 3236 AT PC1163-8460-XP DOT flightsafety DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.CYG.4.58.0701100903410.3236@PC1163-8460-XP.flightsafety.com>
User-Agent: Mutt/1.4.2.2i
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Jan 10 09:37, Brian Ford wrote:
> On Fri, 5 Jan 2007, Corinna Vinschen wrote:
> 
> > Actually this shows a problem in the mmap implementation with respect to
> > MEM_TOP_DOWN.  I think, what mmap should actually do is to create a
> > lightweight MAP_RESERVE anonymous mapping of the whole requested mapping
> > size, then close it again and then reopen it with the address it got
> > in this first try.  This would probably ensure that the subsequent two
> > mapping will work.
> 
> Why MAP_RESERVE if the requested mapping is NO_RESERVE?  This is just
> about whether you have swap (paging file) space initially committed or
> not, right?

MAP_RESERVE is Windows speak, NO_RESERVE is POSIX speak.  Using the same
term doesn't always mean the same.  The MSDN description of VirtualAlloc
is very helpful here.

> > This should work (knock on wood) on all systems now.  My testcases still
> > work on my 512 MB machine, so I'd appreciate if you could give the latest
> > snapshot a try on /3GB enabled machines.
> 
> Yes, this fixes my STC and the application from which it was derived.
> Thanks.

Glad to hear.

> > The 2nd problem: POSIX allows file mappings to exceed the file size,
> > Windows doesn't.  If the code tries to map a bigger size, the file on
> > disk is automatically extended to the size of the map.  The current
> > solution restricts the mapping always to the end of the file, so that it
> > isn't changed by the mapping size.  If the offset is beyond EOF, mmap
> > fails with ENXIO.  My patch uses the AT_EXTENDABLE_FILE flag in a call
> > to ZwMapViewOfSection which allows POSIX semantics.  But as you might
> > guess, this has again a downside.  First, it only works since W2K,
> > second and worse, it only works with PAGE_READWRITE mapping.  Neither
> > PAGE_READONLY, nor PAGE_WRITECOPY (aka MAP_PRIVATE) are allowed.  Oh
> > boy. While PAGE_READONLY can be managed by changing the page protection
> > afterwards, I don't see a way to get it right for MAP_PRIVATE.
> 
> So you mean that POSIX specifies that when a file is mapped larger
> than its size, as read only or private, the on disk file is actually
> extended?  That would have been completely contrary to what I'd expect
> from those two modes.  Otherwise, I don't understand this problem.

Read again.  It's the contrary, as you'd expected.  Briefly, POSIX allows
mappings beyond EOF w/o extending the file size, Windows doesn't.
There's a native NT flag called AT_EXTENDABLE_FILE which allows POSIX
semantics, but only starting with W2K, and only with PAGE_READWRITE, not
with PAGE_WRITECOPY page protection.  PAGE_WRITECOPY is basically what
POSIX calls MAP_PRIVATE, so the AT_EXTENDABLE_FILE flag works only 50/50.

> Also FYI:
> 
> You don't need more memory to enable /3GB on your machine.

Ok, thanks for the info.


Corinna


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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/