tree 198b1d6b43b4e626e9240b8754957a7d13c7bc44
parent 3cad39452004d74c2364ee19074105c2c02a9bfb
author Willy Tarreau <w@1wt.eu> 1507099519 +0200
committer Willy Tarreau <w@1wt.eu> 1507117277 +0200
encoding latin1

BUG/MEDIUM: tcp-check: properly indicate polling state before performing I/O

While porting the connection to use the mux layer, it appeared that
tcp-checks wouldn't receive anymore because the polling is not enabled
before attempting to call xprt->rcv_buf() nor xprt->snd_buf(), and it
is illegal to call these functions with polling disabled as they
directly manipulate the FD state, resulting in an inconsistency where
the FD is enabled and the connection's polling flags disabled.

Till now it happened to work only because when recv() fails on EAGAIN
it calls fd_cant_recv() which enables polling while signaling the
failure, so that next time the message is received. But the connection's
polling is never enabled, and any tiny change resulting in a call to
conn_data_update_polling() immediately disables reading again.

It's likely that this problem already happens on some corner cases
such as multi-packet responses. It definitely breaks as soon as the
response buffer is full but we don't support consuming more than one
response buffer.

This fix should be backported to 1.7 and 1.6. In order to check for the
proper behaviour, this tcp-check must work and clearly show an SSH
banner in recvfrom() as observed under strace, otherwise it's broken :

   tcp-check connect port 22
   tcp-check expect rstring SSH
   tcp-check send blah