From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72215 invoked by alias); 19 Feb 2018 17:19:21 -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 72198 invoked by uid 89); 19 Feb 2018 17:19:19 -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=hood, facet 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 17:19:18 +0000 Received: from perth.hirmke.de (aquarius.franken.de [193.175.24.89]) by mail-n.franken.de (Postfix) with ESMTP id 69A8A721E280D for ; Mon, 19 Feb 2018 18:19:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by perth.hirmke.de (Postfix) with ESMTP id 3E66886064F for ; Mon, 19 Feb 2018 18:19:15 +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 JfTAoqw4HwO4 for ; Mon, 19 Feb 2018 18:19:14 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by perth.hirmke.de (Postfix) with ESMTP id 9D983860647 for ; Mon, 19 Feb 2018 18:19:14 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id 980A5A805B2; Mon, 19 Feb 2018 18:19:14 +0100 (CET) Date: Mon, 19 Feb 2018 17:19:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Atomic mmap replacement Message-ID: <20180219171914.GA3619@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <66bf4f86-4618-b9a3-3e33-2c240b9204d0@cornell.edu> <20180219090042.GC3417@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-SW-Source: 2018-02/txt/msg00213.txt.bz2 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2889 On Feb 19 08:22, Ken Brown wrote: > On 2/19/2018 4:00 AM, Corinna Vinschen wrote: > > On Feb 17 22:37, Ken Brown wrote: > > > Some code in emacs wants to reserve a chunk of address space with a b= ig > > > PROT_NONE anonymous mapping, and then carve it up into separate mappi= ngs > > > associated to segments of a file. This fails on Cygwin. Here's a te= st case > > > that illustrates the problem: > > > [...] > > Several limitations in the Windows kernel disallow this: > >=20 > > - It doesn't allow to unmap parts of a map, only the entire map as a > > whole. > > 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. > >=20 > > - It also disallows to re-map any allocated or mapped mamory for another > > purpose. > >=20 > > So this part of the POSIX specs for mmap: > >=20 > > "The mapping established by mmap() shall replace any previous mappin= gs > > for those whole pages containing any part of the address space of t= he > > process starting at pa and continuing for len bytes" > >=20 > > can't be implemented with Windows means. > >=20 > > 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 On second thought, we *could* do this, if the pages have been mmapped before(*). Unfortunately this would require a *major* revamp of the page handling in mmap. We would have to keep the mapping of every single 64K page separate. I.e., requesting a file mapping of 256K at offset 0 on the POSIX level would have to be handled as four Windows file mappings under the hood: 1. a 64K file mapping at offset 0 2. a 64K file mapping at offset 65536 3. a 64K file mapping at offset 131072 4. a 64K file mapping at offset 196608 A request to mmap another 64K page to the third mapping in this example could then be done by unmapping the third mapping and replace it with the requested mapping. I'm not sure this is feasible. It would complicate and slow down the code especially for big mappings; one call to NtCreateSection and one to NtMapViewOfSection per 64K page, plus the overhead of making sure that all mappings are in the right, sequential order in memory. Plus the overhead of having to remap a lot more mappings in forked children. The "Cygwin is slow" meme would get another interesting facet :} (*) Meaning: We still couldn't call mmap on addresses allocated on the heap. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlqLBxIACgkQ9TYGna5E T6AdwhAAkLiJ3NgqVXQUkEO5ng7sSC1JBXCn17VyTpQ6Tup7likTLxLbZWJG1pRb YLunQb2l8PK/C3EiqmXBGEYs7mBo6bG2d2qFTGhB6pmBKI3yOCZ0vSnmaDmuar2Q eJpDXj+LM+Z7bhKAGP+aRcbXLN1LbWHF66ZsD7v9IQO/l4CsWXZGT8T/u1VYV5qy gcdIoSzxlyyzZu8VpFRXC/ig69/TAz39uGDUkuIysJcUvXqyZemI5kyZGt422HFH iH7/i/LezfHLCbal0Q2ar81DLvTKprU+1y66ILm+ONqHMHPk0BXd9X38r+Guy/nP hMvdq6EgWk9YKYd9DP4H3Uqo8iOfgEelPbiV6ZE4r9EuP15nS9sY7cL1hQSSLFaZ FRh8wQTrsT9gjKm0nMpDoSw5Y9WqIq0QlE/TI04XfsCZcYvybRD7mbMqSuyf4qxd 5GvlA3KidA5Er7v8cpPst4kbQN4k5i+xgMmNZh2MblM+z0tmIOGij9EcVgvn4g29 zR2sj5jOh1Db12aTfMuu1jpjpgMs43TdSnfw+mVgja0gm/pT/3xdeq+wwY34zya/ h7eVZRUsFeagOy0QhWfxi/g3FM6iWM/7UhaZ/JKOEoukYAs5fJEbtaXbfJracuiU DdtCbuBg1vR3nK4YT/VfepA5Bz6peyaUHPWxRdoRGB7Z2KYw/80= =6+l0 -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh--