Am 11.03.2017 um 13:45 schrieb Willy Tarreau: > I don't understand, the bisection didn't end ? > > Otherwise I'm inclined to think that the regression comes from > "BUG/MEDIUM: tcp: don't poll for write when connect() succeeds", which > it the one I proposed you to revert and which didn't change anything. > > Did "git bisect" end up telling you "This is the first bad commit" ?
I had a typo, here the result (typed git bisect goog instead of good): cd4c5a3ecf5e77fb4734c423c914f7280199c763 is the first bad commit commit cd4c5a3ecf5e77fb4734c423c914f7280199c763 Author: Willy Tarreau <[email protected]> Date: Wed Jan 25 14:12:22 2017 +0100 BUG/MEDIUM: tcp: don't poll for write when connect() succeeds While testing a tcp_fastopen related change, it appeared that in the rare case where connect() can immediately succeed, we still subscribe to write notifications on the socket, causing the conn_fd_handler() to immediately be called and a second call to connect() to be attempted to double-check the connection. In fact this issue had already been met with unix sockets (which often respond immediately) and partially addressed but incorrect so another patch will follow. But for TCP nothing was done. The fix consists in removing the WAIT_L4_CONN flag if connect() succeeds and to subscribe for writes only if some handshakes or L4_CONN are still needed. In addition in order not to fail raw TCP health checks, we have to continue to enable polling for data when nothing is scheduled for leaving and the connection is already established, otherwise the caller will never be notified. This fix should be backported to 1.7 and 1.6. (cherry picked from commit 819efbf4b532d718abeb5e5aa6b2521ed725fe17) :040000 040000 438a30304ac086b5cf0b0670253ff12efefeac82 6f2d45215d45de5669d3789eac247df856117e69 M src Gruß Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook
