From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-04.nifty.com (conssluserg-04.nifty.com [210.131.2.83]) by sourceware.org (Postfix) with ESMTPS id 9E6F13857C60 for ; Fri, 27 Aug 2021 11:25:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9E6F13857C60 Received: from Express5800-S70 (z221123.dynamic.ppp.asahi-net.or.jp [110.4.221.123]) (authenticated) by conssluserg-04.nifty.com with ESMTP id 17RBOcsK001556; Fri, 27 Aug 2021 20:24:38 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com 17RBOcsK001556 X-Nifty-SrcIP: [110.4.221.123] Date: Fri, 27 Aug 2021 20:24:40 +0900 From: Takashi Yano To: cygwin@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-Id: <20210827202440.47706fc2fc07c5e9a1bc0047@nifty.ne.jp> In-Reply-To: <3b560051-ab27-f392-ca4b-d1fd9b5733b0@cornell.edu> References: <41A583E1-C8E7-42AB-9F24-EEC33A41EC60@house.org> <20210825201845.07b6400b79dc5558a7761efe@nifty.ne.jp> <20210826062934.54f2f2216021c095bb7ba13b@nifty.ne.jp> <3b560051-ab27-f392-ca4b-d1fd9b5733b0@cornell.edu> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__27_Aug_2021_20_24_40_+0900_lf.Jf5F5Tm0BrY/F" X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: Fri, 27 Aug 2021 11:25:21 -0000 This is a multi-part message in MIME format. --Multipart=_Fri__27_Aug_2021_20_24_40_+0900_lf.Jf5F5Tm0BrY/F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Thu, 26 Aug 2021 18:18:29 -0400 Ken Brown wrote: > On 8/26/2021 11:56 AM, Ken Brown via Cygwin wrote: > > On 8/25/2021 5:29 PM, Takashi Yano wrote: > >> On Wed, 25 Aug 2021 13:52:19 -0400 > >> Ken Brown wrote: > >>> On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote: > >>>> On Tue, 24 Aug 2021 12:49:52 -0700 > >>>> Chris Roehrig wrote: > >>>>> I have a network of Windows, Linux and Mac machines and I use rsync to > >>>>> synchronize various directories between them. > >>>>> > >>>>> I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only > >>>>> when the remote endpoint is Cygwin rsync over sshd (with both a Linux or > >>>>> Cygwin rsync client).   In all other scenarios, I get the full 100MB/s as > >>>>> expected from gigabit ethernet.  This has been an ongoing problem for me > >>>>> for a couple of years over several Windows and Cygwin versions, and I'd > >>>>> like to try to fix it. > >>>>> > >>>>> If I run rsync --daemon --no-detach under mintty in the foreground on the > >>>>> remote Windows endpoint,  I get the full 100 MB/s transfers, so it seems > >>>>> like it has something to do with rsync.exe running in the background under > >>>>> the cygrunsrv+sshd service (which was installed normally using > >>>>> ssh-host-config). > >>>>> > >>>>> If I do: > >>>>>     pv /dev/zero | ssh $WINHOST "cat > /dev/null" > >>>>> or even > >>>>>     pv /dev/urandom | ssh $WINHOST md5sum > >>>>> I also get the full 100 MB/s transfers, so it doesn't look like sshd itself > >>>>> is being throttled by bandwidth or CPU. > >>>>> > >>>>> The machines have less than 15% CPU utilization while transferring, with > >>>>> each of the 4 cores less than 30%, so it doesn't look to be CPU issue. > >>>>> In Task Manager, sshd.exe and rsync.exe seem to be running normally using > >>>>> only few percent CPU, and show Power Throttling=Disabled, > >>>>> Priority=Normal.   Setting their Priority to High doesn't seem to change > >>>>> things. > >>>>> > >>>>> Looking in Resource Monitor on the remote endpoint, the network usage is > >>>>> pretty much a flat horizontal line at about 18 Mbps (2.5 MB/s), so it sure > >>>>> looks to me as if rsync is somehow being bandwidth-throttled when run in > >>>>> the background under cygsshd. > >>>>> > >>>>> It's almost as if rsync has an implicit --bwlimit override when it is run > >>>>> from cygrunsrv+sshd (I've tried --bwlimit=0 on the client which makes no > >>>>> difference). > >>>>> > >>>>> > >>>>> Any ideas?    Not sure where to go from here. > >>>> > >>>> In cygwin, just scp is very slow. > >>>> > >>>> The transfer speed in my environment is as follows. > >>>> The tests were done with 100MB of test.dat file. > >>>> > >>>> (1-1) From cygwin-PC, > >>>> [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:. > >>>> yano@linux-server's password: > >>>> test.dat                                      100%  100MB   4.0MB/s   00:24 > >>>> [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat . > >>>> yano@linux-server's password: > >>>> test.dat                                      100%  100MB   8.0MB/s   00:12 > >>>> > >>>> (1-2) From linux-server, > >>>> yano@linux-server:~$ scp yano@cygwin-PC:test.dat . > >>>> yano@cygwin-PC's password: > >>>> test.dat                                      100%  100MB   4.0MB/s   00:24 > >>>> yano@linux-server:~$ scp test.dat yano@cygwin-PC:. > >>>> yano@cygwin-PC's password: > >>>> test.dat                                      100%  100MB   4.1MB/s   00:24 > >>>> > >>>> > >>>> I looked into this problem, and noticed that this is caused > >>>> by cygwin pipe implementation. Pipe in cygwin is configured > >>>> with FILE_FLAG_OVERLAPPED. > >>>> > >>>> If the pipe is configured without FILE_FLAG_OVERLAPPED, > >>>> the transfer speed is much improved as follows. > >>>> > >>>> > >>>> (2-1) From cygwin-PC, > >>>> [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:. > >>>> yano@linux-server's password: > >>>> test.dat                                      100%  100MB  85.5MB/s   00:01 > >>>> [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat . > >>>> yano@linux-server's password: > >>>> test.dat                                      100%  100MB  69.7MB/s   00:01 > >>>> > >>>> (2-2) From linux-server, > >>>> yano@linux-server:~$ scp yano@cygwin-PC:test.dat . > >>>> yano@cygwin-PC's password: > >>>> test.dat                                      100%  100MB  80.1MB/s   00:01 > >>>> yano@linux-server:~$ scp test.dat yano@cygwin-PC:. > >>>> yano@cygwin-PC's password: > >>>> test.dat                                      100%  100MB  57.7MB/s   00:01 > >>>> > >>>> I am not sure why this happens and how to fix this. > >>> > >>> A couple years ago I had an idea for changing the pipe implementation to avoid > >>> overlapped I/O: > >>> > >>>     https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html > >>>     https://cygwin.com/pipermail/cygwin-patches/2019q2/009423.html > >>> > >>> I never followed up on it.  But if you think it might help with this problem, I > >>> could dust it off and try to finish it. > >> > >> Interesting. > >> > >> It will be also helpfull for: > >> https://cygwin.com/pipermail/cygwin/2021-March/247987.html > >> which seems to be the same issue with > >> https://stackoverflow.com/questions/10385424/good-alternatives-to-cygwin-cygwin-doesnt-support-natively-support-win32-app > >> > >> > >> However, I wonder why scp dislikes overlapped I/O. > > > > I agree that it would be good to understand this.  When I first proposed the > > change, I was thinking in terms of code simplification.  If it also improves > > performance (which we don't know yet), it becomes a higher priority, but in that > > case it would be nice to understand why it improves performance. > > Hi Takashi, > > In case you want to try out my proposed change, I've just rebased the patches to > the current master and pushed them to a new topic/pipe branch. Hi Ken, Thanks much! I tested topic/pipe branch. [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:. yano@linux-server's password: test.dat 100% 100MB 95.9MB/s 00:01 [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat . yano@linux-server's password: test.dat 100% 100MB 8.0MB/s 00:12 yano@linux-server:~$ scp yano@cygwin-PC:test.dat . yano@cygwin-PC's password: test.dat 100% 100MB 109.7MB/s 00:00 yano@linux-server:~$ scp test.dat yano@cygwin-PC:. yano@cygwin-PC's password: test.dat 100% 100MB 31.4MB/s 00:03 As shown above, outgoing transfer-rate has been improved upto near theoretical limit. However, incoming transfer-rate is not improved much. I digged further and found the first patch attached solves the issue as follows. [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat . yano@linux-server's password: test.dat 100% 100MB 112.8MB/s 00:00 yano@linux-server2:~$ scp test.dat yano@cygwin-PC:. yano@cygwin-PC's password: test.dat 100% 100MB 102.5MB/s 00:00 I also tested the case: > >> https://cygwin.com/pipermail/cygwin/2021-March/247987.html > >> which seems to be the same issue with > >> https://stackoverflow.com/questions/10385424/good-alternatives-to-cygwin-cygwin-doesnt-support-natively-support-win32-app Unfortunately, topic/pipe does not help. I confirmed that applying the second patch attached, which reverts to create() rather than nt_create(), and setting CYGWIN=pipe_byte fixes the problem. What do you think of this alternative implementation which does not use nt_create()? -- Takashi Yano --Multipart=_Fri__27_Aug_2021_20_24_40_+0900_lf.Jf5F5Tm0BrY/F Content-Type: application/octet-stream; name="0001-Cygwin-select-Improve-select-poll-response.patch" Content-Disposition: attachment; filename="0001-Cygwin-select-Improve-select-poll-response.patch" Content-Transfer-Encoding: base64 RnJvbSBjMmVjZWNlYTczMWZiNjMzYTllMTA2NjZkNzU0NmUxYzYxYzhjNGY3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBUYWthc2hpIFlhbm8gPHRha2FzaGkueWFub0BuaWZ0eS5uZS5q cD4KRGF0ZTogRnJpLCAyNyBBdWcgMjAyMSAxOTo1NDo0MSArMDkwMApTdWJqZWN0OiBbUEFUQ0gg MS8yXSBDeWd3aW46IHNlbGVjdDogSW1wcm92ZSBzZWxlY3QvcG9sbCByZXNwb25zZS4KCi0tLQog d2luc3VwL2N5Z3dpbi9zZWxlY3QuY2MgfCAzMiArKysrKysrKysrKysrKysrKysrKysrKysrKysr LS0tLQogMSBmaWxlIGNoYW5nZWQsIDI4IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCgpk aWZmIC0tZ2l0IGEvd2luc3VwL2N5Z3dpbi9zZWxlY3QuY2MgYi93aW5zdXAvY3lnd2luL3NlbGVj dC5jYwppbmRleCA4YWQ5ODJjMTIuLjgzZTFjMDBlMCAxMDA2NDQKLS0tIGEvd2luc3VwL2N5Z3dp bi9zZWxlY3QuY2MKKysrIGIvd2luc3VwL2N5Z3dpbi9zZWxlY3QuY2MKQEAgLTczNSw2ICs3MzUs NyBAQCB0aHJlYWRfcGlwZSAodm9pZCAqYXJnKQogICBzZWxlY3RfcGlwZV9pbmZvICpwaSA9IChz ZWxlY3RfcGlwZV9pbmZvICopIGFyZzsKICAgRFdPUkQgc2xlZXBfdGltZSA9IDA7CiAgIGJvb2wg bG9vcGluZyA9IHRydWU7CisgIERXT1JEIHQwID0gR2V0VGlja0NvdW50ICgpOwogCiAgIHdoaWxl IChsb29waW5nKQogICAgIHsKQEAgLTc1NCw3ICs3NTUsMTIgQEAgdGhyZWFkX3BpcGUgKHZvaWQg KmFyZykKIAlicmVhazsKICAgICAgIGN5Z3dhaXQgKHBpLT5ieWUsIHNsZWVwX3RpbWUgPj4gMyk7 CiAgICAgICBpZiAoc2xlZXBfdGltZSA8IDgwKQotCSsrc2xlZXBfdGltZTsKKwl7CisJICBEV09S RCB0MSA9IEdldFRpY2tDb3VudCAoKTsKKwkgIGlmICh0MCAhPSB0MSkKKwkgICAgKytzbGVlcF90 aW1lOworCSAgdDAgPSB0MTsKKwl9CiAgICAgICBpZiAocGktPnN0b3BfdGhyZWFkKQogCWJyZWFr OwogICAgIH0KQEAgLTkzMCw2ICs5MzYsNyBAQCB0aHJlYWRfZmlmbyAodm9pZCAqYXJnKQogICBz ZWxlY3RfZmlmb19pbmZvICpwaSA9IChzZWxlY3RfZmlmb19pbmZvICopIGFyZzsKICAgRFdPUkQg c2xlZXBfdGltZSA9IDA7CiAgIGJvb2wgbG9vcGluZyA9IHRydWU7CisgIERXT1JEIHQwID0gR2V0 VGlja0NvdW50ICgpOwogCiAgIHdoaWxlIChsb29waW5nKQogICAgIHsKQEAgLTk0OSw3ICs5NTYs MTIgQEAgdGhyZWFkX2ZpZm8gKHZvaWQgKmFyZykKIAlicmVhazsKICAgICAgIGN5Z3dhaXQgKHBp LT5ieWUsIHNsZWVwX3RpbWUgPj4gMyk7CiAgICAgICBpZiAoc2xlZXBfdGltZSA8IDgwKQotCSsr c2xlZXBfdGltZTsKKwl7CisJICBEV09SRCB0MSA9IEdldFRpY2tDb3VudCAoKTsKKwkgIGlmICh0 MCAhPSB0MSkKKwkgICAgKytzbGVlcF90aW1lOworCSAgdDAgPSB0MTsKKwl9CiAgICAgICBpZiAo cGktPnN0b3BfdGhyZWFkKQogCWJyZWFrOwogICAgIH0KQEAgLTExMjUsNiArMTEzNyw3IEBAIHRo cmVhZF9jb25zb2xlICh2b2lkICphcmcpCiAgIHNlbGVjdF9jb25zb2xlX2luZm8gKmNpID0gKHNl bGVjdF9jb25zb2xlX2luZm8gKikgYXJnOwogICBEV09SRCBzbGVlcF90aW1lID0gMDsKICAgYm9v bCBsb29waW5nID0gdHJ1ZTsKKyAgRFdPUkQgdDAgPSBHZXRUaWNrQ291bnQgKCk7CiAKICAgd2hp bGUgKGxvb3BpbmcpCiAgICAgewpAQCAtMTE0NCw3ICsxMTU3LDEyIEBAIHRocmVhZF9jb25zb2xl ICh2b2lkICphcmcpCiAJYnJlYWs7CiAgICAgICBjeWd3YWl0IChjaS0+YnllLCBzbGVlcF90aW1l ID4+IDMpOwogICAgICAgaWYgKHNsZWVwX3RpbWUgPCA4MCkKLQkrK3NsZWVwX3RpbWU7CisJewor CSAgRFdPUkQgdDEgPSBHZXRUaWNrQ291bnQgKCk7CisJICBpZiAodDAgIT0gdDEpCisJICAgICsr c2xlZXBfdGltZTsKKwkgIHQwID0gdDE7CisJfQogICAgICAgaWYgKGNpLT5zdG9wX3RocmVhZCkK IAlicmVhazsKICAgICB9CkBAIC0xMzY0LDYgKzEzODIsNyBAQCB0aHJlYWRfcHR5X3NsYXZlICh2 b2lkICphcmcpCiAgIHNlbGVjdF9waXBlX2luZm8gKnBpID0gKHNlbGVjdF9waXBlX2luZm8gKikg YXJnOwogICBEV09SRCBzbGVlcF90aW1lID0gMDsKICAgYm9vbCBsb29waW5nID0gdHJ1ZTsKKyAg RFdPUkQgdDAgPSBHZXRUaWNrQ291bnQgKCk7CiAKICAgd2hpbGUgKGxvb3BpbmcpCiAgICAgewpA QCAtMTM4Myw3ICsxNDAyLDEyIEBAIHRocmVhZF9wdHlfc2xhdmUgKHZvaWQgKmFyZykKIAlicmVh azsKICAgICAgIGN5Z3dhaXQgKHBpLT5ieWUsIHNsZWVwX3RpbWUgPj4gMyk7CiAgICAgICBpZiAo c2xlZXBfdGltZSA8IDgwKQotCSsrc2xlZXBfdGltZTsKKwl7CisJICBEV09SRCB0MSA9IEdldFRp Y2tDb3VudCAoKTsKKwkgIGlmICh0MCAhPSB0MSkKKwkgICAgKytzbGVlcF90aW1lOworCSAgdDAg PSB0MTsKKwl9CiAgICAgICBpZiAocGktPnN0b3BfdGhyZWFkKQogCWJyZWFrOwogICAgIH0KLS0g CjIuMzMuMAoK --Multipart=_Fri__27_Aug_2021_20_24_40_+0900_lf.Jf5F5Tm0BrY/F Content-Type: application/octet-stream; name="0002-Cygwin-pipe-Revert-to-create-rather-than-nt_create.patch" Content-Disposition: attachment; filename="0002-Cygwin-pipe-Revert-to-create-rather-than-nt_create.patch" Content-Transfer-Encoding: base64 RnJvbSA3ODQ4OTJkYzI3MmE2Yjc4OTlkZTVmODljNjViYjhjZmFiNzk1OTFkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBUYWthc2hpIFlhbm8gPHRha2FzaGkueWFub0BuaWZ0eS5uZS5q cD4KRGF0ZTogRnJpLCAyNyBBdWcgMjAyMSAyMDowNjowNCArMDkwMApTdWJqZWN0OiBbUEFUQ0gg Mi8yXSBDeWd3aW46IHBpcGU6IFJldmVydCB0byBjcmVhdGUoKSByYXRoZXIgdGhhbiBudF9jcmVh dGUoKS4KCi0tLQogd2luc3VwL2N5Z3dpbi9maGFuZGxlcl9waXBlLmNjIHwgMjQgKysrKysrKysr KysrKysrKysrKysrKystCiAxIGZpbGUgY2hhbmdlZCwgMjMgaW5zZXJ0aW9ucygrKSwgMSBkZWxl dGlvbigtKQoKZGlmZiAtLWdpdCBhL3dpbnN1cC9jeWd3aW4vZmhhbmRsZXJfcGlwZS5jYyBiL3dp bnN1cC9jeWd3aW4vZmhhbmRsZXJfcGlwZS5jYwppbmRleCAyZGVjMGE4NDguLmIzYWY0YTBhMCAx MDA2NDQKLS0tIGEvd2luc3VwL2N5Z3dpbi9maGFuZGxlcl9waXBlLmNjCisrKyBiL3dpbnN1cC9j eWd3aW4vZmhhbmRsZXJfcGlwZS5jYwpAQCAtMjM0LDYgKzIzNCwyNCBAQCBmaGFuZGxlcl9waXBl OjpyYXdfcmVhZCAodm9pZCAqcHRyLCBzaXplX3QmIGxlbikKICAgICAgIHJldHVybjsKICAgICB9 CiAKKyAgaWYgKGlzX25vbmJsb2NraW5nICgpKQorICAgIHsKKyAgICAgIERXT1JEIG47CisgICAg ICBCT09MIHJldCA9IFBlZWtOYW1lZFBpcGUgKGdldF9oYW5kbGUgKCksIE5VTEwsIDAsIE5VTEws ICZuLCBOVUxMKTsKKyAgICAgIGlmICghcmV0KQorCXsKKwkgIF9fc2V0ZXJybm8gKCk7CisJICBs ZW4gPSAoc2l6ZV90KSAtMTsKKwkgIHJldHVybjsKKwl9CisgICAgICBpZiAobiA9PSAwKQorCXsK KwkgIHNldF9lcnJubyAoRUFHQUlOKTsKKwkgIGxlbiA9IChzaXplX3QpIC0xOworCSAgcmV0dXJu OworCX0KKyAgICB9CisKICAgZG8KICAgICB7CiAgICAgICBsZW4gPSBvcmlnX2xlbjsKQEAgLTU3 MSw2ICs1ODksNyBAQCBmaGFuZGxlcl9waXBlOjpjcmVhdGUgKExQU0VDVVJJVFlfQVRUUklCVVRF UyBzYV9wdHIsIFBIQU5ETEUgciwgUEhBTkRMRSB3LAogICByZXR1cm4gMDsKIH0KIAorI2lmIDAK IC8qIFRoZSBuZXh0IHZlcnNpb24gb2YgZmhhbmRsZXJfcGlwZTo6Y3JlYXRlIHVzZWQgdG8gY2Fs bCB0aGUgcHJldmlvdXMKICAgIHZlcnNpb24uICBCdXQgdGhlIHJlYWQgaGFuZGxlIGNyZWF0ZWQg YnkgdGhlIGxhdHRlciBkb2Vzbid0IGhhdmUKICAgIEZJTEVfV1JJVEVfQVRUUklCVVRFUyBhY2Nl c3MgdW5sZXNzIHRoZSBwaXBlIGlzIGNyZWF0ZWQgd2l0aApAQCAtNTg4LDYgKzYwNyw3IEBAIGZo YW5kbGVyX3BpcGU6OmNyZWF0ZSAoTFBTRUNVUklUWV9BVFRSSUJVVEVTIHNhX3B0ciwgUEhBTkRM RSByLCBQSEFORExFIHcsCiAKIHN0YXRpYyBpbnQgbnRfY3JlYXRlIChMUFNFQ1VSSVRZX0FUVFJJ QlVURVMsIFBIQU5ETEUsIFBIQU5ETEUsIERXT1JELAogCQkgICAgICBpbnQ2NF90ICopOworI2Vu ZGlmCiAKIGludAogZmhhbmRsZXJfcGlwZTo6Y3JlYXRlIChmaGFuZGxlcl9waXBlICpmaHNbMl0s IHVuc2lnbmVkIHBzaXplLCBpbnQgbW9kZSkKQEAgLTU5Nyw3ICs2MTcsNyBAQCBmaGFuZGxlcl9w aXBlOjpjcmVhdGUgKGZoYW5kbGVyX3BpcGUgKmZoc1syXSwgdW5zaWduZWQgcHNpemUsIGludCBt b2RlKQogICBpbnQgcmVzID0gLTE7CiAgIGludDY0X3QgdW5pcXVlX2lkOwogCi0gIGludCByZXQg PSBudF9jcmVhdGUgKHNhLCAmciwgJncsIHBzaXplLCAmdW5pcXVlX2lkKTsKKyAgaW50IHJldCA9 IGNyZWF0ZSAoc2EsICZyLCAmdywgcHNpemUsIE5VTEwsIDAsICZ1bmlxdWVfaWQpOwogICBpZiAo cmV0KQogICAgIF9fc2V0ZXJybm9fZnJvbV93aW5fZXJyb3IgKHJldCk7CiAgIGVsc2UgaWYgKChm aHNbMF0gPSAoZmhhbmRsZXJfcGlwZSAqKSBidWlsZF9maF9kZXYgKCpwaXBlcl9kZXYpKSA9PSBO VUxMKQpAQCAtNjI0LDYgKzY0NCw3IEBAIGZoYW5kbGVyX3BpcGU6OmNyZWF0ZSAoZmhhbmRsZXJf cGlwZSAqZmhzWzJdLCB1bnNpZ25lZCBwc2l6ZSwgaW50IG1vZGUpCiAgIHJldHVybiByZXM7CiB9 CiAKKyNpZiAwCiBzdGF0aWMgaW50CiBudF9jcmVhdGUgKExQU0VDVVJJVFlfQVRUUklCVVRFUyBz YV9wdHIsIFBIQU5ETEUgciwgUEhBTkRMRSB3LAogCQlEV09SRCBwc2l6ZSwgaW50NjRfdCAqdW5p cXVlX2lkKQpAQCAtNzU1LDYgKzc3Niw3IEBAIG50X2NyZWF0ZSAoTFBTRUNVUklUWV9BVFRSSUJV VEVTIHNhX3B0ciwgUEhBTkRMRSByLCBQSEFORExFIHcsCiAgIC8qIFN1Y2Nlc3MuICovCiAgIHJl dHVybiAwOwogfQorI2VuZGlmCiAKIGludAogZmhhbmRsZXJfcGlwZTo6aW9jdGwgKHVuc2lnbmVk IGludCBjbWQsIHZvaWQgKnApCi0tIAoyLjMzLjAKCg== --Multipart=_Fri__27_Aug_2021_20_24_40_+0900_lf.Jf5F5Tm0BrY/F--