From: Amaury Denoyelle <adenoyelle@haproxy.com>
Date: Mon, 9 Oct 2023 14:15:20 +0000 (+0200)
Subject: BUG/MINOR: mux-quic: support initial 0 max-stream-data
X-Git-Tag: v2.9-dev8~79
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9d905dfd73f3b5025ba0bd3ede0713fad2df826e;p=thirdparty%2Fhaproxy.git

BUG/MINOR: mux-quic: support initial 0 max-stream-data

Support stream opening with an initial max-stream-data of 0.

In normal case, QC_SF_BLK_SFCTL is set when a qcs instance cannot
transfer more data due to flow-control. This flag is set when
transfering data from MUX to quic-conn instance.

However, it's possible to define an initial value of 0 for
max-stream-data. In this case, qcs instance is blocked despite
QC_SF_BLK_SFCTL not set. No STREAM frame is prepared for this stream as
it's not possible to emit any byte, so QC_SF_BLK_SFCTL flag is never
set.

This behavior should cause no harm. However, this can cause a BUG_ON()
crash on qcc_io_send(). Indeed, when sending is retried, it ensures that
only qcs instance waiting for a new qc_stream_buf or with
QC_SF_BLK_SFCTL set is present in the send_list.

To fix this, initialize qcs with 0 value for msd and QC_SF_BLK_SFCTL.
The flag is removed only if transport parameter msd value is non null.

This should be backported up to 2.6.
---

diff --git a/src/mux_quic.c b/src/mux_quic.c
index 8a765190e5..5be382fab4 100644
--- a/src/mux_quic.c
+++ b/src/mux_quic.c
@@ -131,6 +131,10 @@ static struct qcs *qcs_new(struct qcc *qcc, uint64_t id, enum qcs_type type)
 		qcs->tx.msd = qcc->rfctl.msd_uni_l;
 	}
 
+	/* Properly set flow-control blocking if initial MSD is nul. */
+	if (!qcs->tx.msd)
+		qcs->flags |= QC_SF_BLK_SFCTL;
+
 	qcs->rx.ncbuf = NCBUF_NULL;
 	qcs->rx.app_buf = BUF_NULL;
 	qcs->rx.offset = qcs->rx.offset_max = 0;