BUG/MEDIUM: mux-quic: Unblock zero-copy forwarding if the txbuf can be released

In done_fastfwd() callback function, if nothing was forwarding while the SD
is blocked, it means there is not enough space in the buffer to proceed. It
may be because there are data to be sent. But it may also be data already
sent waiting for an ack. In this case, no data to be sent by the mux. So the
quic stream is not woken up when data are finally removed from the
buffer. The data forwarding can thus be stuck. This happens when the stats
page is requested in QUIC/H3. Only applets are affected by this issue and
only with the QUIC multiplexer because it is the only mux with already sent
data in the TX buf.

To fix the issue, the idea is to release the txbuf if possible and then
unblock the SD to perform a new zero-copy data forwarding attempt. Doing so,
and thanks to the previous patch ("MEDIUM: applet: Be able to unblock
zero-copy data forwarding from done_fastfwd"), the applet will be woken up.

This patch should fix the issue #2584. It must be backported to 3.0.

(cherry picked from commit 792a645)
Signed-off-by: Amaury Denoyelle <[email protected]>

Author: capflam

src/mux_quic.c

@@ -3046,8 +3046,16 @@ static size_t qmux_strm_done_ff(struct stconn *sc)
 		qcs->flags |= QC_SF_FIN_STREAM;
 	}
 
-	if (!(qcs->flags & QC_SF_FIN_STREAM) && !sd->iobuf.data)
+	if (!(qcs->flags & QC_SF_FIN_STREAM) && !sd->iobuf.data) {
+		TRACE_STATE("no data sent", QMUX_EV_STRM_SEND, qcs->qcc->conn, qcs);
+
+		/* There is nothing to forward and the SD is blocked. Try to
+		 * release the TXBUF to retry.
+		 */
+		if ((qcs->sd->iobuf.flags & IOBUF_FL_FF_BLOCKED) && !qcc_release_stream_txbuf(qcs))
+			qcs->sd->iobuf.flags &= ~IOBUF_FL_FF_BLOCKED;
 		goto end;
+	}
 
 	data += sd->iobuf.offset;
 	total = qcs->qcc->app_ops->done_ff(qcs);