]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: quic: fix tasklet_wakeup loop on connection closing
authorAmaury Denoyelle <adenoyelle@haproxy.com>
Fri, 11 Aug 2023 14:10:34 +0000 (16:10 +0200)
committerAmaury Denoyelle <adenoyelle@haproxy.com>
Fri, 11 Aug 2023 15:04:20 +0000 (17:04 +0200)
commit7f80d518124af10a5f8734bcf801dffc49ee2a10
treee65460a1d2f56e59ccc7b573bfa39558afa1923b
parentd355bce7e4f64f61c62a7e5f036c9599d37139ae
BUG/MEDIUM: quic: fix tasklet_wakeup loop on connection closing

It is possible to trigger a loop of tasklets calls if a QUIC connection
is interrupted abruptly by the client. This is caused by the following
interaction :
* FD iocb is woken up for read. This causes a wakeup on quic_conn
  tasklet.
* quic_conn_io_cb is run and try to read but fails as the connection
  socket is closed (typically with a ECONNREFUSED). FD read is
  subscribed to the poller via qc_rcv_buf() which will cause the loop.

The looping will stop automatically once the idle-timeout is expired and
the connection instance is finally released.

To fix this, ensure FD read is subscribed only for transient error cases
(EAGAIN or similar). All other cases are considered as fatal and thus
all future read operations will fail. Note that for the moment, nothing
is reported on the quic_conn which may not skip future reception. This
should be improved in a future commit to accelerate connection closing.

This bug can be reproduced on a frequent occurence by interrupting the
following command. Quic traces should be activated on haproxy side to
detect the loop :
$ ngtcp2-client --tp-file=/tmp/ngtcp2-tp.txt \
  --session-file=/tmp/ngtcp2-session.txt \
  -r 0.3 -t 0.3 --exit-on-all-streams-close 127.0.0.1 20443 \
  "http://127.0.0.1:20443/?s=1024"

This must be backported up to 2.7.
src/quic_sock.c