From: Willy Tarreau Date: Tue, 3 Dec 2019 17:08:45 +0000 (+0100) Subject: BUG/MEDIUM: stream-int: don't subscribed for recv when we're trying to flush data X-Git-Tag: v2.2-dev1~218 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=1ac5f208042ff571c9341aed0380ca52c084a261;p=thirdparty%2Fhaproxy.git BUG/MEDIUM: stream-int: don't subscribed for recv when we're trying to flush data If we cannot splice incoming data using rcv_pipe() due to remaining data in the buffer, we must not subscribe to the mux but instead tag the stream-int as blocked on missing Rx room. Otherwise when data are flushed, calling si_chk_rcv() will have no effect because the WAIT_EP flag remains present, and we'll end in an rx timeout. This case is very hard to reproduce, and requires an inversion of the polling side in the middle of a transfer. This can only happen when the client and the server are using similar links and when splicing is enabled. It typically takes hundreds of MB to GB for the problem to happen, and tends to be magnified by the use of option contstats which causes process_stream() to be called every 5s and to try again to recv. This fix must be backported to 2.1, 2.0, and possibly 1.9. --- diff --git a/src/stream_interface.c b/src/stream_interface.c index e673e0f5a5..aa9cf20324 100644 --- a/src/stream_interface.c +++ b/src/stream_interface.c @@ -1355,6 +1355,13 @@ int si_cs_recv(struct conn_stream *cs) } if (ret <= 0) { + /* if we refrained from reading because we asked for a + * flush to satisfy rcv_pipe(), we must not subscribe + * and instead report that there's not enough room + * here to proceed. + */ + if (flags & CO_RFL_BUF_FLUSH) + si_rx_room_blk(si); break; }