DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DCD293858407
Date: Wed, 8 Sep 2021 10:18:40 +0200
To: cygwin@cygwin.com
Subject: Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow
 -- throttled?]
Message-ID: <YThx4K4s55y6WzTv@calimero.vinschen.de>
Mail-Followup-To: cygwin@cygwin.com
References: <40275f71-7c10-55a9-e6c8-a948e32c37ac@cornell.edu>
 <YTY0oN9x7wNtJAKx@calimero.vinschen.de>
 <d3c9bb17-b859-e7b1-d7e6-c421d0f37836@cornell.edu>
 <33ae27cb-4e45-7484-40d1-6cbd88c958f1@cornell.edu>
 <YTZXGlvWWUk23bJI@calimero.vinschen.de>
 <YTZY/vytb7nagC6M@calimero.vinschen.de>
 <3a63eb8c-3e8e-cd2c-b9de-8c34fa041a75@cornell.edu>
 <5b705ae7c9747a9cc25d2610cc6748e92bbe1d70.camel@dontech.dk>
 <890dad21-dec5-cdd1-bf99-bdb45e759a71@cornell.edu>
 <742331ee-4d9f-e86f-9314-c85b5f0cbfa8@SystematicSw.ab.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <742331ee-4d9f-e86f-9314-c85b5f0cbfa8@SystematicSw.ab.ca>
Precedence: list
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit

On Sep  6 21:34, Brian Inglis wrote:
> On 2021-09-06 15:24, Ken Brown via Cygwin wrote:
> > On 9/6/2021 4:54 PM, Peter Dons Tychsen wrote:
> > > Hi there,
> > > 
> > > On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
> > > > > No, wait.  I get what you say.  The optimzation settings of the test
> > > > > case should have no influence on the code inside the DLL.  That
> > > > > doesn't
> > > > > make sense for sure.  However, I ran the testcase under GDB, I could
> > > > > reproduce the issue, and I could fix it by setting mmap_ext.Reserved
> > > > > = 0;
> > > > > Go figure!
> > > > 
> > > > I don't get it, but I can confirm that the problem is fixed.
> > > 
> > > That sounds a bit like a voodoo fix, that could quickly regress again.
> > > 
> > > Here is my 2 cents:
> > > 
> > > Currently the mmap_ext structure is setup like this:
> > > 
> > >   215       MEM_EXTENDED_PARAMETER mmap_ext = {
> > >   216         .Type = MemExtendedParameterAddressRequirements,
> > >   217         .Pointer = (PVOID) &mmap_req
> > >   218       };
> > > 
> > > This means that all other entries in the struct are zero at
> > > initialization as described here:
> > > https://en.cppreference.com/w/c/language/struct_initialization
> > > 
> > > So if you set "mmap_ext.Reserved = 0" again after that its a double
> > > failure.
> > 
> > You're looking at the wrong source code.  The bug didn't occur until the
> > code was changed to do the following:
> > 
> >        /* g++ 11.2 workaround: don't use initializer */
> >        MEM_EXTENDED_PARAMETER mmap_ext;
> >        mmap_ext.Type = MemExtendedParameterAddressRequirements;
> >        mmap_ext.Pointer = (PVOID) &mmap_req;
> > 
> > This left mmap_ext.Reserved uninitialized, which Corinna has now fixed.
> 
> With undocumented structure member initialization an issue, maybe better to
> future proof using e.g.
> 
> 	MEM_EXTENDED_PARAMETER mmap_ext = { 0 }; // or memset or bzero
> 	...

You're right.  The bits in Reserved are just that, reserved.  So MSFT
may decide to use some of the  bits for other purposes, should the need
arise.  I've fixed that in git master.


Thanks,
Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple