From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93950 invoked by alias); 19 Feb 2018 13:22:43 -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 90372 invoked by uid 89); 19 Feb 2018 13:22:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: limerock03.mail.cornell.edu Received: from limerock03.mail.cornell.edu (HELO limerock03.mail.cornell.edu) (128.84.13.243) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Feb 2018 13:22:41 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock03.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id w1JDMdwL026982 for ; Mon, 19 Feb 2018 08:22:39 -0500 Received: from [192.168.0.15] (mta-68-175-129-7.twcny.rr.com [68.175.129.7] (may be forged)) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id w1JDMb0d014130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 19 Feb 2018 08:22:38 -0500 Subject: Re: Atomic mmap replacement To: cygwin@cygwin.com References: <66bf4f86-4618-b9a3-3e33-2c240b9204d0@cornell.edu> <20180219090042.GC3417@calimero.vinschen.de> From: Ken Brown Message-ID: Date: Mon, 19 Feb 2018 13:22:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180219090042.GC3417@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Cornell-Gauge: Gauge=XXXXX X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00205.txt.bz2 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 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 case >> that illustrates the problem: >> >> $ truncate -s 64k foo >> >> $ cat mmap_test.c >> #include >> #include >> #include >> #include >> >> const size_t page_size = 64 * 1024; >> >> int >> main () >> { >> void *mem = mmap (NULL, 2 * page_size, >> PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); >> if (mem == MAP_FAILED) >> { >> perror ("mmap"); >> exit (1); >> } >> int fd = open ("foo", O_RDONLY); >> void *res = mmap (mem, page_size, PROT_READ | PROT_WRITE, >> MAP_PRIVATE | MAP_FIXED, fd, 0); >> if (res == MAP_FAILED) >> { >> perror ("mmap"); >> exit (2); >> } >> } >> >> $ gcc mmap_test.c >> >> $ ./a >> mmap: Invalid argument >> >> $ echo $? >> 2 >> >> 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. > > 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. Thanks, Corinna. I'll take this information back to the emacs list. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple