From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by sourceware.org (Postfix) with ESMTPS id AD67A386F82E for ; Wed, 22 Jul 2020 18:48:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AD67A386F82E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=corinna-cygwin@cygwin.com Received: from calimero.vinschen.de ([217.91.18.234]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MDy9C-1k8FwJ05XI-00A10y for ; Wed, 22 Jul 2020 20:48:31 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 8F884A81007; Wed, 22 Jul 2020 20:48:30 +0200 (CEST) Date: Wed, 22 Jul 2020 20:48:30 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: page_size vs allocation_granularity Message-ID: <20200722184830.GV16360@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <3ac8f341-1dbe-b407-de64-4a2d5c191e68@cornell.edu> <20200722083327.GR16360@calimero.vinschen.de> <3e8c9ae9-cfa7-f4db-d243-dc9593b252e9@cornell.edu> <5eaa60f8-37d5-1d73-7ec7-679ca0cce3c9@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5eaa60f8-37d5-1d73-7ec7-679ca0cce3c9@cornell.edu> X-Provags-ID: V03:K1:jizCR90nFwimGwMgP24QmiVljAPEVVx5WMoLTOy6E1jisLsqEwl e79rkoDN+3HiSk0OhUag1RgZGILuio7txNp7+hgrmfYJIAmn34PEsu7cYXZub/utYf6dA0l NATGzWg1f1wcWBkHM2vq7ekcI6UcZn4tDNcbD4OfMnxD6K/8Fb+k1/urE6TLgGlqoEq4jJJ c0QY5cXn8XxJgtBGfITbg== X-UI-Out-Filterresults: notjunk:1;V03:K0:oYhhZcyYDrY=:abNBqH2fnIEn5XQ5Q4EGSW NqbMlPZZKkHeCVQAtqegIU0j/YvVcwEooqA/ttImRgW1tZmG4XbIEoRF48UEChWPsc35VMxAD KHt8jg1jf9P3SshpwNaR42wBpP+z33evkMO16dmobaawkftZim9EK48nHGF8ZN9PwMdYT6Kei j6re7vhtZXcqtF0wBf+WuNpvrV7vuZDQjuyt9G6dWfM5riS/f5/5yROhO+7L1Z0O8sNoEx+6k CYSIxn5QQdQfGDEuopjLo0Zew20hAa4PZi/AZK3xpd10WUEGDychqEP+FRU3V/lBallPYWXgY +heAa9gJgvBHGi5JT3+UpnN6zSaEwpT16w8bIPSo6haCAAIup7CbV8Yqhwsl2DbQlDKHULjnw SsSdEvCStNmFmvXEKd4cC/bZ9hd9dF2ZiD2MiEpgW/+CuE47qLKIUhByo2FL/v5QvOlahKxS3 UJulnn7W/+GKs2Q6kq8FGCIRmHhXPatGKA2aKrn1EEr4z7CKmlzd5cQlVSFJGYGJTSnv6B43Q VRGaWINstHF1pbEwwxRSweMmbronpoDT7ctrKnBCaCtnhf5Wyc31fVUNn3sQQIt6bRly93wql PApout9ROm0R1eZiYcU8qudq8fgFMTUqozS+UOFeDxsRJGN74hZZM9aBdPJEsPF4KJsVo2iZB d6vr8a+3HCpvz1poMzRwlHbftsL7nudUxrsH1ao3mlR7fUaLbMSbYmnIeBxtqflGWGwuW/tXH p5Rp5LdvQr83Zjzhy7tDE7jHCur9cHl3wsViqnCQL9KKLkmQxWhifo1BmRvfkh2bXtiYbpXvc UL9tYpm9a7PHEwMoB2YcL6MRUyCJ1Dy9SDRyZLRlIe171g8bx92m+l0bVuLkUeIByZpe1WC0y iu5/2lwgOssJ5xVkGTww== X-Spam-Status: No, score=-99.7 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 18:48:34 -0000 On Jul 22 14:35, Ken Brown via Cygwin-developers wrote: > On 7/22/2020 12:42 PM, Ken Brown via Cygwin-developers wrote: > > On 7/22/2020 4:33 AM, Corinna Vinschen wrote: > > > If php reads or writes in the remainder of the block constituting EOF, > > > or tries to change page protection, shit happens.  Every time, a process > > > stabs into the EOF block following the last valid 4K block, it results > > > in a STATUS_ACCESS_VIOLATION which in turn calls > > > mmap_is_attached_or_noreserve().  While this situation can be > > > recognized, I don't see a way to fix this from the processes POV. > > > > So that's exactly what happens when php maps a file whose size is a > > multiple of 4K but not a multiple of 64K.  It expects that there is a > > zero-filled region beyond EOF that it can safely read from. > > Interestingly, you mentioned exactly this scenario in 2002 as a reason for > keeping the pagesize at 4K rather than 64K: > > https://cygwin.com/pipermail/cygwin/2002-January/068154.html Yeah, it took quite some time for me to realize that a 64K pagesize is usually the better approach for POSIX compatibility. And the fact that AT_ROUND_TO_PAGE worked nicely on 32 bit (and 64 bit way off) helped, too. I was pretty stubborn back then... I hope that changed. > I have nothing new to contribute, so we should probably just drop this. My > curiosity has been satisfied. I toyed around with Windows mappings today, all the stuff I already tried since 2000 over and over again. Still no joy. Corinna -- Corinna Vinschen Cygwin Maintainer