]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: mux-quic: Don't unblock zero-copy fwding if blocked during nego
authorChristopher Faulet <cfaulet@haproxy.com>
Tue, 4 Jun 2024 16:10:51 +0000 (18:10 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Wed, 5 Jun 2024 05:28:10 +0000 (07:28 +0200)
commit9748df29ff655a9626d6e75ea9db79bb9afa2a50
treee54d976d97c3432e4c673d6b1c51c24eeec71aee
parent2bde0d64ddf0e32257444f14e69adea8f899b74b
BUG/MEDIUM: mux-quic: Don't unblock zero-copy fwding if blocked during nego

The previous fix (792a645ec2 ["BUG/MEDIUM: mux-quic: Unblock zero-copy
forwarding if the txbuf can be released"]) introduced a regression. The
zero-copy data forwarding must only be unblocked if it was blocked by the
producer, after a successful negotiation.

It is important because during a negotiation, the consumer may be blocked
for another reason. Because of the flow control for instance. In that case,
there is not necessarily a TX buffer. And it unexpected to try to release an
unallocated TX buf.

In addition, the same may happen while a TX buf is still in-use. In that
case, it must also not be released. So testing the TX buffer is not the
right solution.

To fix the issue, a new IOBUF flag was added (IOBUF_FL_FF_WANT_ROOM). It
must be set by the producer if it is blocked after a sucessful negotiation
because it needs more room. In that case, we know a buffer was provided by
the consummer. In done_fastfwd() callback function, it is then possible to
safely unblock the zero-copy data forwarding if this flag is set.

This patch must be backported to 3.0 with the commit above.
include/haproxy/stconn-t.h
include/haproxy/stconn.h
src/applet.c
src/mux_quic.c