From 792a645ec21126c74c33820d1e0de63ee98aa810 Mon Sep 17 00:00:00 2001 From: Christopher Faulet Date: Tue, 4 Jun 2024 12:04:48 +0200 Subject: [PATCH] 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. --- src/mux_quic.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/mux_quic.c b/src/mux_quic.c index ae504ee65..64b8ac0a3 100644 --- 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);