X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 47111382E057 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1594839291; bh=LZ1Icf+jBpyY1f1ZM/YC3sz8MHdl+0o3LXc4prTg04Q=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=n0OvuXTl6u0cHa8iEmybR3cmsEjUOyvteO622p7DGwr7u95l9jlTw0eFDhD1tmMbN 2tfXkJGaFMdMytb2cktDDI4svdCJXrTKYddcPoKyH4P/cmbqGpFd9Q7vxqGObhp5dd bN8QQwW7O1jWPyZ8pp75t+sY13aDI4vLQWsmB+LY= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EEB883840C3D X-Virus-Scanned: Debian amavisd-new at policy02-mors.netcup.net X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 Received-SPF: pass (mx2f80: connection is authenticated) To: cygwin AT cygwin DOT com Subject: [PATCH] Fix poll/select signal socket as write ready on connect failure Message-ID: Date: Wed, 15 Jul 2020 20:54:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------71E77180C2D8C7988932DBF1" X-PPP-Message-ID: <159483928064 DOT 12200 DOT 3338737208583855976 AT mx2f80 DOT netcup DOT net> X-PPP-Vhost: marc-hoersken.de X-NC-CID: hXxgaaURgGdiYRS7cCJzJxQnaMeLf82za9DziQQLMnLqS4IsBg== X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 List-Id: General Cygwin discussions and problem reports List-Archive: List-Post: List-Help: List-Subscribe: , From: Marc Hoersken via Cygwin Reply-To: Marc Hoersken Sender: "Cygwin" This is a multi-part message in MIME format. --------------71E77180C2D8C7988932DBF1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello everyone, I identified an issue related to the way the events FD_CONNECT and=20 FD_CLOSE returned by WSAEnumNetworkEvents are currently handled in=20 winsup/cygwin/fhandler_socket_inet.cc. It seems like the code does not handle the fact that those events are=20 returned only once for a socket and if not acted upon by the calling=20 program may not be received again. This means poll and select are=20 currently not consistend about the socket still being writable after a=20 connect failure. The first call to poll or select would signal the=20 socket as writable, but not any following call. The first call consumes=20 the FD_CONNECT and FD_CLOSE events, regardless of the event mask=20 supplied by the calling program. So even if the calling program does not=20 care about writability in the first call, the events are consumed and=20 following calls checking for writability will not be able to detect a=20 connection failure. A very simple test to reproduce can be made with the Cygwin provided=20 curl package. After installing with current Cygwin, issue the following=20 command to make it try connecting to a local non-listening port (eg. 47): curl -v 127.0.0.1:47 With current Cygwin this will never timeout. An explanation of the curl=20 internals can be found here [1], but the short version is: curl waits on=20 sockets without checking/handling writability in a first poll call and=20 then after waiting, the writability (connection failure) is checked in a=20 second poll call per wait-loop iteration. Therefore curl can never=20 detect the connection failure in the second call, because the first call=20 already consumed the relevant events. As far as I understand calling poll and/or select should not=20 change/reset the socket readyness state, therefore I created a simple=20 fix which could be used to solve this issue. Attached you will find a=20 suggested patch to make sure poll and select always signal writability=20 of a connection failed socket. With this patch applied the above example=20 command failed with a "Connection refused" as expected. This patch only fixes the behaviour regarding connection failure (during=20 FD_CONNECT), I am not sure if connection closure (during FD_CLOSE) is=20 also affected, but I was not able to find code handling the fact that=20 FD_CLOSE is only signalled once. Please take a look and thanks in advance! Best regards, Marc H=C3=B6rsken [1] https://github.com/curl/curl/pull/5509#issuecomment-658357933 --------------71E77180C2D8C7988932DBF1 Content-Type: text/plain; charset=UTF-8; name="0001-Cygwin-make-sure-failed-sockets-always-signal-writab.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0001-Cygwin-make-sure-failed-sockets-always-signal-writab.pa"; filename*1="tch" RnJvbSA3Y2Q5ZDU5N2EyYTMxNGMzYWViNWI3YzhhYWE5NzBkZWQ2ZDU2ZDdhIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBNYXJjIEhvZXJza2VuIDxpbmZvQG1hcmMtaG9lcnNr ZW4uZGU+CkRhdGU6IFdlZCwgMTUgSnVsIDIwMjAgMjA6NTM6MjEgKzAyMDAKU3ViamVjdDog W1BBVENIXSBDeWd3aW46IG1ha2Ugc3VyZSBmYWlsZWQgc29ja2V0cyBhbHdheXMgc2lnbmFs IHdyaXRhYmlsaXR5CgpTaW5jZSBGRF9DT05ORUNUIGlzIG9ubHkgZ2l2ZW4gb25jZSwgd2Ug bWFudWFsbHkgbmVlZCB0byBzZXQKRkRfV1JJVEUgZm9yIGNvbm5lY3Rpb24gZmFpbGVkIHNv Y2tldHMgdG8gaGF2ZSBjb25zaXN0ZW50CmJlaGF2aW91ciBpbiBwcm9ncmFtcyBjYWxsaW5n IHBvbGwvc2VsZWN0IG11bHRpcGxlIHRpbWVzLgoKRXhhbXBsZSB0ZXN0IHRvIG5vbi1saXN0 ZW5pbmcgcG9ydDogY3VybCAtdiAxMjcuMC4wLjE6NDcKLS0tCiB3aW5zdXAvY3lnd2luL2Zo YW5kbGVyX3NvY2tldF9pbmV0LmNjIHwgNiArKysrKysKIDEgZmlsZSBjaGFuZ2VkLCA2IGlu c2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS93aW5zdXAvY3lnd2luL2ZoYW5kbGVyX3NvY2tl dF9pbmV0LmNjIGIvd2luc3VwL2N5Z3dpbi9maGFuZGxlcl9zb2NrZXRfaW5ldC5jYwppbmRl eCA3NGM0MTVkLi5lNWIwZDJkIDEwMDY0NAotLS0gYS93aW5zdXAvY3lnd2luL2ZoYW5kbGVy X3NvY2tldF9pbmV0LmNjCisrKyBiL3dpbnN1cC9jeWd3aW4vZmhhbmRsZXJfc29ja2V0X2lu ZXQuY2MKQEAgLTM3Niw2ICszNzYsMTIgQEAgZmhhbmRsZXJfc29ja2V0X3dzb2NrOjpldmFs dWF0ZV9ldmVudHMgKGNvbnN0IGxvbmcgZXZlbnRfbWFzaywgbG9uZyAmZXZlbnRzLAogICAg ICAgaWYgKGVyYXNlKQogCXdzb2NrX2V2ZW50cy0+ZXZlbnRzICY9IH4oZXZlbnRzICYgfihG RF9XUklURSB8IEZEX0NMT1NFKSk7CiAgICAgfQorICAvKiBTaW5jZSBGRF9DT05ORUNUIGlz IG9ubHkgZ2l2ZW4gb25jZSwgd2UgbWFudWFsbHkgbmVlZCB0byBzZXQKKyAgICAgRkRfV1JJ VEUgZm9yIGNvbm5lY3Rpb24gZmFpbGVkIHNvY2tldHMgdG8gaGF2ZSBjb25zaXN0ZW50Cisg ICAgIGJlaGF2aW91ciBpbiBwcm9ncmFtcyBjYWxsaW5nIHBvbGwvc2VsZWN0IG11bHRpcGxl IHRpbWVzLgorICAgICBFeGFtcGxlIHRlc3QgdG8gbm9uLWxpc3RlbmluZyBwb3J0OiBjdXJs IC12IDEyNy4wLjAuMTo0NyAqLworICBpZiAoKGNvbm5lY3Rfc3RhdGUgKCkgPT0gY29ubmVj dF9mYWlsZWQpICYmIChldmVudF9tYXNrICYgRkRfV1JJVEUpKQorICAgIHdzb2NrX2V2ZW50 cy0+ZXZlbnRzIHw9IEZEX1dSSVRFOwogICBVTkxPQ0tfRVZFTlRTOwogCiAgIHJldHVybiBy ZXQ7Ci0tIAoyLjcuNAoK --------------71E77180C2D8C7988932DBF1 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- 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 --------------71E77180C2D8C7988932DBF1--