page_size vs allocation_granularity
Wed Jul 22 18:48:30 GMT 2020
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:
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.
More information about the Cygwin-developers