From f6e193f1b05bc3a73090b1efeb3f0440a0c776b0 Mon Sep 17 00:00:00 2001 From: Christopher Faulet Date: Mon, 9 Sep 2024 18:19:54 +0200 Subject: [PATCH] BUG/MAJOR: mux-h1: Wake SC to perform 0-copy forwarding in CLOSING state When the mux is woken up on I/O events, if the zero-copy forwarding is enabled, receives are blocked. In this case, the SC is woken up to be able to perform 0-copy forwarding to the other side. This works well, except for the H1C in CLOSING state. Indeed, in that case, in h1_process(), the SC is not woken up because only RUNNING H1 connections are considered. As consequence, the mux will ignore connection closure. The H1 connection remains blocked, waiting for the shutdown timeout. If no timeout is configured, the H1 connection is never closed leading to a leak. This patch should fix leak reported by Damien Claisse in the issue #2697. It should be backported as far as 2.8. --- src/mux_h1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mux_h1.c b/src/mux_h1.c index 058474f62..b4d3e5bfb 100644 --- a/src/mux_h1.c +++ b/src/mux_h1.c @@ -4112,7 +4112,7 @@ static int h1_process(struct h1c * h1c) } } - if (h1c->state == H1_CS_RUNNING && (h1c->flags & H1C_F_WANT_FASTFWD) && !h1s_data_pending(h1c->h1s)) { + if (h1c->state >= H1_CS_RUNNING && (h1c->flags & H1C_F_WANT_FASTFWD) && !h1s_data_pending(h1c->h1s)) { TRACE_DEVEL("xprt rcv_buf blocked (want_fastfwd), notify h1s for recv", H1_EV_H1C_RECV, h1c->conn); h1_wake_stream_for_recv(h1c->h1s); }