From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by sourceware.org (Postfix) with ESMTPS id DCD293858407 for ; Wed, 8 Sep 2021 08:18:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DCD293858407 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MXGes-1mRcvn1ZWw-00YkgS for ; Wed, 08 Sep 2021 10:18:41 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id E179BA80D9E; Wed, 8 Sep 2021 10:18:40 +0200 (CEST) Date: Wed, 8 Sep 2021 10:18:40 +0200 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?] Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <40275f71-7c10-55a9-e6c8-a948e32c37ac@cornell.edu> <33ae27cb-4e45-7484-40d1-6cbd88c958f1@cornell.edu> <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-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <742331ee-4d9f-e86f-9314-c85b5f0cbfa8@SystematicSw.ab.ca> X-Provags-ID: V03:K1:QVxUl5993H9cSix+RVPwYIlDP95LKCih/Wkp1oLrOGl5ssYEq38 sKw+lywTLiKjpFXHPR8lWw2+EyvtHK5GkBw26swMzv63gBNJAfkPbTPjap3iLt5sg1kIlY7 OcCcgHwXW2110y0DorWC3Rc7YBXWe4KQ+4VNaiV4ny29hGDmRZFOjgxeiAmFMY1qCSErcci Bg4Cs1W3zxS1Yw6yWPl6A== X-UI-Out-Filterresults: notjunk:1;V03:K0:u201yGhhJjQ=:f/91tdF6c7n80FCjHz184B Sk1AAFZZizqdT9XB9Ji9YQMl7l0XNbw3wIlekZcvN1Ny2b994N44uJHVdxCp8y//Is1oCfzFS RiIGGCDCyQPxHx8TZ2EgpJQac7xqEAOVMmi2fh8iiPfl3Dz5jXBmwrEfVM0AYv/81AoFQJLRU 43q2io9Vjrnk6B4lRs8oUTs4v/2dwdB+C04MPORQQ756I3xxuoAG5mtddenLV5wFpdEA+MXQC CId8Ul7WmsgGmByNoqh4Bzaty8e03+rxkjzzMD3zs6juIwNV0CFvXpYYZVJWeFmIVkdy7iSGx u5B7a+xEKrjL7PtMU+/7K9rrk8A471Ac1QnnIItAoOQVvAeaJ8bDKzyYpb/lhfdZa18E1EaoO wZ3T4P8fvXIp6T4GmxTzVieUkojUfh1ZvQGoKHYA9vg+hNVdhT8J9swzAqNeVoLG0IHUgHhBw MDRcvCPm8AJz+oqboL+Fn4j+N5jlFVBTrJVCRt66jHQ85ywRpd/kV6hhBE6XdttcWEccEkPzR KT58GDtcf8TvdraTpm6C2iQ7bGhPvUw+ISFgCMVD85e53CAhzO94cbOW3RNticlFj7p9UBnH2 KqxQsPrEg1YHLyg6eIF8xvwJ7mWMpxzoEXWtC0k4reHiPEh+KXVynx/6ytMbWa46U2Fa+OSzf wdWgYo72RL6LqX69u5T3SqIaNxQH70lD9xYDSzVayJyoiAKnH8H+mHlML1QFij/+Znbn176CQ ktOauli900m8YE/JMhQscXlkGiyyG2cJy7OJGpHrWEh8zbxNkbcG8IdA5nE= X-Spam-Status: No, score=-98.5 required=5.0 tests=BAYES_00, BODY_8BITS, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 08:18:47 -0000 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