]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
MINOR: mux-h2: try to clear DEM_MROOM and MUX_MFULL at more places
authorWilly Tarreau <w@1wt.eu>
Mon, 2 Sep 2024 13:14:16 +0000 (15:14 +0200)
committerWilly Tarreau <w@1wt.eu>
Tue, 3 Sep 2024 12:39:04 +0000 (14:39 +0200)
The code leading to H2_CF_MUX_MFULL and H2_CF_DEM_MROOM being cleared
is quite complex and assumptions about its state are extremely difficult
when reading the code. There are indeed long sequences where the mux might
possibly be empty, still having the flag set until it reaches h2_send()
which will clear it after the last send. Even then it's not obviour whether
it's always guaranteed to release the flag when invoked in multiple passes.
Let's just simplify the conditionnn so that h2_send() does not depend on
"sent" anymore and that h2_timeout_task() doesn't leave the flags set on
the buffer on emptiness. While it doesn't seem to fix anything, it will
make the code more robust against future changes.

src/mux_h2.c

index d6583cc1adf2f8b0fe8f668dc3e5b13a7916879a..3457afdde726cff00d5e9b71ba4cd58bdb03e5a7 100644 (file)
@@ -4321,7 +4321,7 @@ static int h2_send(struct h2c *h2c)
                 * data from the other side when it's known that this one is
                 * still congested.
                 */
-               if (sent && br_single(h2c->mbuf))
+               if (br_single(h2c->mbuf))
                        h2c->flags &= ~(H2_CF_MUX_MFULL | H2_CF_DEM_MROOM);
        }
 
@@ -4672,6 +4672,12 @@ do_leave:
                        offer_buffers(NULL, released);
        }
 
+       /* Above we might have prepared a GOAWAY that was sent along with
+        * pending data, make sure to clear the FULL flags.
+        */
+       if (br_single(h2c->mbuf))
+               h2c->flags &= ~(H2_CF_MUX_MFULL | H2_CF_DEM_MROOM);
+
        /* in any case this connection must not be considered idle anymore */
        if (h2c->conn->flags & CO_FL_LIST_MASK) {
                HA_SPIN_LOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);