]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: stream-int: clear CO_FL_WAIT_ROOM after splicing data in
authorWilly Tarreau <w@1wt.eu>
Thu, 15 Nov 2018 14:52:53 +0000 (15:52 +0100)
committerWilly Tarreau <w@1wt.eu>
Thu, 15 Nov 2018 16:00:08 +0000 (17:00 +0100)
commit81464b4e4df822b9613e61af565d0384e9f8d3ec
tree6e5ad03d405eb29eaa39cfeb4d3d792a325fd095
parentf6975aa9202c27c50d4272e0fc37067700a28c0f
BUG/MEDIUM: stream-int: clear CO_FL_WAIT_ROOM after splicing data in

Since we don't necessarily pass through conn_fd_handler() when reading,
conn_refresh_polling_flags() is not necessarily called when performing
a recv() operation, thus flags like CO_FL_WAIT_ROOM are not cleared.

It happens that si_cs_recv() checks CO_FL_WAIT_ROOM before deciding to
receive into a buffer, to see if the previous rcv_pipe() call failed by
lack of pipe room. The combined effect of these two statements is that
at the end of a file transmission, when there's too little data to
warrant the use of a pipe and the pipe is empty, we refrain from using
rcv_pipe() for the last few bytes, but since CO_FL_WAIT_ROOM is still
present, we don't use rcv_buf() either, and the connection remains
frozen in this state with si_cs_recv() called in loops.

In order to fix this we can simply manually clear CO_FL_WAIT_ROOM when
not using pipe so that the next check sees the result of the previous
operation and not an old one. We could equally call
cond_refresh_polling_flags() but that would be overkill and dangerous
given that it would manipulate the connection's flags under the mux.
By the way ideally the mux should report this flag into the connstream
for cleaner manipulation.

No backport is needed as this is only post 1.9-dev2.
src/stream_interface.c