tree 7cdafe84e89b9df4dc938c20eaf72c48aabc9ee1
parent 6b0a8505035a8df7587c7867b75c0bd4a55eae1f
author Willy Tarreau <w@1wt.eu> 1353657395 +0100
committer Willy Tarreau <w@1wt.eu> 1353657839 +0100
encoding latin1

BUG/MEDIUM: checks: ensure we completely disable polling upon success

When a check succeeds, it used to only disable receive events while
it should disable both directions. The problem is that if the send
event was reported too, it could re-enable the recv event. In theory
this is not a problem as the task is going to be woken up, but if
there are many tasks in the queue and this task is not processed
immediately, we could theorically face a storm of unprocessed events
(typically POLL_HUP).

So better stop both directions, prevent the send side from enabling
recv and have the process_chk() code enable both directions. This
will also help detecting closes before the check is sent.

Note that all this mess has been inherited from the old code that used
the fd as a flag to report if a check was running. We should have a
dedicated flag and perform the fd_delete() in wake_srv_chk() instead.