From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63483 invoked by alias); 19 Feb 2018 09:01:07 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 49147 invoked by uid 89); 19 Feb 2018 09:00:54 -0000 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 Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Feb 2018 09:00:52 +0000 Received: from perth.hirmke.de (aquarius.franken.de [193.175.24.89]) by mail-n.franken.de (Postfix) with ESMTP id 3EB36721E2823 for ; Mon, 19 Feb 2018 10:00:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by perth.hirmke.de (Postfix) with ESMTP id EC4B7860E0F for ; Mon, 19 Feb 2018 10:00:43 +0100 (CET) X-Spam-Score: -2.9 Received: from perth.hirmke.de ([127.0.0.1]) by localhost (perth.hirmke.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GdQBufUHGB8V for ; Mon, 19 Feb 2018 10:00:42 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by perth.hirmke.de (Postfix) with ESMTP id 258E8860DE5 for ; Mon, 19 Feb 2018 10:00:42 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id 19274A80678; Mon, 19 Feb 2018 10:00:42 +0100 (CET) Date: Mon, 19 Feb 2018 09:01:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Atomic mmap replacement Message-ID: <20180219090042.GC3417@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <66bf4f86-4618-b9a3-3e33-2c240b9204d0@cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <66bf4f86-4618-b9a3-3e33-2c240b9204d0@cornell.edu> User-Agent: Mutt/1.9.2 (2017-12-15) X-SW-Source: 2018-02/txt/msg00202.txt.bz2 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2598 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 > #include > #include > #include >=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" Content-length: 833 -----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--