mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2025-09-20 21:31:28 +02:00
9748df29ff
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.