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.

diff --git a/src/mux_quic.c b/src/mux_quic.c
index ae504ee652433767b167c7e58faed10cc9fb1fe5..64b8ac0a3888a24bcc7d598edab82d9ee9a90eba 100644 (file)
--- a/src/mux_quic.c
+++ b/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);