mirror of
https://github.com/haproxy/haproxy.git
synced 2026-04-04 00:25:08 -04:00
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.
This commit is contained in:
parent
d85f9f9d43
commit
9d905dfd73
1 changed files with 4 additions and 0 deletions
|
|
@ -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;
|
||||
|
|
|
|||
Loading…
Reference in a new issue