Re: page_size vs allocation_granularity

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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