X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=OvBUudqfPFxS6iZ48qtuCnn05Th0f1qVwo7tDNNYD4/8RLilIz5jn
	culDYNS/pp4zjNhjrr6+NigYVoayEvVTlumkEMHj4UPz92o3goPW6XXK0U16ZE6F
	EDakCdXuCWuByeihpLoKcGGfglQPIUmabxYuMu8XuXndE4oE+7V5DI=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=4CONzHfjV3kD0Y1ugHbGJ4/pAJU=; b=nzDj6wiiO5cy4x2NsP44ffmwQ03m
	+I+wMHIjvRgcRmjpK4dUqipOGQTUwH0Jwm98DMs1ZLE8qKGfkIVLMDpNrKbeMm3C
	rEZTzwtAmZcZ55Li/ez7lyskLIlftlxGnAEpvIEOOIUMbj22dlquucy1HV/tYc/D
	xrObbVQq+h1GoOU=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-101.9 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=
X-HELO:	drew.franken.de
X-Spam-Score:	-2.9
Date:	Mon, 19 Feb 2018 10:00:42 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Atomic mmap replacement
Message-ID:	<20180219090042.GC3417@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<66bf4f86-4618-b9a3-3e33-2c240b9204d0 AT cornell DOT edu>
MIME-Version:	1.0
In-Reply-To:	<66bf4f86-4618-b9a3-3e33-2c240b9204d0@cornell.edu>
User-Agent:	Mutt/1.9.2 (2017-12-15)

--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb 17 22:37, Ken Brown wrote:
> Some code in emacs wants to reserve a chunk of address space with a big
> PROT_NONE anonymous mapping, and then carve it up into separate mappings
> associated to segments of a file.  This fails on Cygwin.  Here's a test c=
ase
> that illustrates the problem:
>=20
> $ truncate -s 64k foo
>=20
> $ cat mmap_test.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <fcntl.h>
> #include <sys/mman.h>
>=20
> const size_t page_size =3D 64 * 1024;
>=20
> int
> main ()
> {
>   void *mem =3D mmap (NULL, 2 * page_size,
>                     PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>   if (mem =3D=3D MAP_FAILED)
>     {
>       perror ("mmap");
>       exit (1);
>     }
>   int fd =3D open ("foo", O_RDONLY);
>   void *res =3D mmap (mem, page_size, PROT_READ | PROT_WRITE,
>                     MAP_PRIVATE | MAP_FIXED, fd, 0);
>   if (res =3D=3D MAP_FAILED)
>     {
>       perror ("mmap");
>       exit (2);
>     }
> }
>=20
> $ gcc mmap_test.c
>=20
> $ ./a
> mmap: Invalid argument
>=20
> $ echo $?
> 2
>=20
> Is this a bug, or is it simply a limitation of Cygwin's mmap?  If the
> latter, is there a simple workaround?

Several limitations in the Windows kernel disallow this:

- It doesn't allow to unmap parts of a map, only the entire map as a
  whole.
=20=20
  Cygwin has a workaround: If you unmap parts of a map it just keeps
  track of this and sets the protection of the affected pages to
  PAGE_NOACCESS.  In case of anonymous mappings, it even recycles them
  potentially for other mappings.

- It also disallows to re-map any allocated or mapped mamory for another
  purpose.

So this part of the POSIX specs for mmap:

  "The mapping established by mmap() shall replace any previous mappings
   for those whole pages containing any part of the address space of the
   process starting at pa and continuing for len bytes"

can't be implemented with Windows means.

The only workaround possible would be to handle this *exact* scenario as
a special case in Cygwin's mmap:  If the new mapping falls in the middle
of an existing mapping and if the original mapping was an anonymous
mapping with PROT_NONE page protection, then

- unmap the old mapping
- remap the unaffected parts as separate anonymous mapping
- map the affected parts for the requested file mapping

This is pretty complicated and I'm not hot on implementing it.  If it's
really required we can take a look of course.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--qDbXVdCdHGoSgWSk
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlqKkjkACgkQ9TYGna5E
T6CdGA//SY9ISdZyub3qIyT9LU0e6PgRvs5Z8tA35bYuj7d9OM2DYwLwvCOse83d
t+khMzvq38QANk0PV+z6OHDltK0HmZo9Jpl3utJrQaT/ganIRE02pv2JzRyjthBB
vQGg05chcKiRDhrJfJZdrYH5N3GwLARafOT/WSP4bWE9uX/gbi5dngzK6VLIusRK
TuriLEUJumG8mv12dGy4azsCO+z9oby74WG8D2mTXTyJiuGXIGTylTzEEVMjDmtk
3OzvthaVLrvDUpgp76bPUaeLJutFd0gpUpchYMBf2+P11SWK3QAZHfSVTUpnb1Ly
6C+McFodr4kmKt8ok8Jv9IQa4ccw2vgZmTQ30wIZt13REFn2UEUSGwXFiiG4SnbM
szYbuyRN3o95oEEH/rSeikDVC9wWuTmVvI91XeMY3jAh/hSlc31LzN6ndzd/skn/
WOmplQiQ8+A6IMmPD81Vu1xDIGPeD/Srf2oDx+dee7eq1fPOQHaibcj6cw0+WzWw
T/sw9RZlRD2slDLFEDzD1qZw2Z4pXWJpefK7ygDbl25Q8NY+bzvmCENcyGKTOGN7
V/P2SWOPCs1lMYZMq1P6t1gZRqpMw/m86xzGEJfTEDyyan/S+6OmD8E2GeY+4WMH
/Lr6k/7xFs5NWobydxnT3nnMy2UwyeH1FHumHaaefUwoHGt7zKs=
=7yrZ
-----END PGP SIGNATURE-----

--qDbXVdCdHGoSgWSk--

- Raw text -