Christopher Faulet 9748df29ff 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.
2024-06-05 07:28:10 +02:00
..
2023-08-01 10:49:06 +02:00
2023-01-27 15:18:59 +01:00
2023-04-13 16:57:51 +02:00
2024-04-05 15:40:42 +02:00
2024-04-26 11:29:25 +02:00
2024-05-16 10:31:17 +02:00
2021-11-18 10:50:58 +01:00
2022-04-22 15:45:47 +02:00
2024-05-16 10:58:20 +02:00
2024-05-16 10:58:20 +02:00
2022-11-29 15:14:39 +01:00
2024-01-26 17:29:27 +01:00
2023-05-04 18:09:50 +02:00
2024-05-29 15:00:02 +02:00