aboutgitcodebugslistschat
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2026-05-21 16:37:43 +1000
committerStefano Brivio <sbrivio@redhat.com>2026-05-26 12:21:41 +0200
commitbda823050fba6351b3e9dbf557020bb3ec399d64 (patch)
treefd46b023afa435bcd54b2f213a6dbfc6cd4cbd63
parentaa6b796b1ce10fb1f5ab0f11f1bacfb04f97291d (diff)
downloadpasst-bda823050fba6351b3e9dbf557020bb3ec399d64.tar
passt-bda823050fba6351b3e9dbf557020bb3ec399d64.tar.gz
passt-bda823050fba6351b3e9dbf557020bb3ec399d64.tar.bz2
passt-bda823050fba6351b3e9dbf557020bb3ec399d64.tar.lz
passt-bda823050fba6351b3e9dbf557020bb3ec399d64.tar.xz
passt-bda823050fba6351b3e9dbf557020bb3ec399d64.tar.zst
passt-bda823050fba6351b3e9dbf557020bb3ec399d64.zip
tcp_splice: Avoid missing EOF recognition while forwarding
tcp_splice_sock_handler() has an optimised path for the common case where the amount we splice(2) into the pipe is exactly the same as the amount we splice(2) out again. If the pipe is empty at that point, we stop forwarding until we get another epoll event. However, via a subtle chain of events, this can cause a bug for a half-closed connection. Suppose the connection is already half-closed in the other direction - that is, we've already called shutdown(SHUT_WR) on the socket for which we're getting the event. In this event we're getting the last batch of data in the other direction, and also a FIN. This can result in EPOLLIN, EPOLLRDHUP and EPOLLHUP events simultaneously. We read the last data from the socket and successfully splice it to the other side. Since there is no data in the pipe, we exit the forwarding loop. However, because we did read data, we don't set the eof flag. Because we don't set eof, we don't (yet) propagate the FIN to the other side, or set FIN_SENT_(!fromsidei). Therefore we don't (yet) recognize this as a clean termination and set the CLOSING flag. We would correct this when we get our next event, however before we can do so we process the EPOLLHUP event. Because we haven't recognized this as a clean close we assume it is an abrupt close and send an RST to the other side. To avoid this, don't stop attempting to forward data on this path. Continue for at least one more loop. If we're at EOF, we'll recognize it on the next splice(2). If not it gives us an opportunity to forward more data without returning to the mail epoll loop. Reported-by: Paul Holzinger <pholzing@redhat.com> Link: https://bugs.passt.top/show_bug.cgi?id=202 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
-rw-r--r--tcp_splice.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/tcp_splice.c b/tcp_splice.c
index 915ac11..762a058 100644
--- a/tcp_splice.c
+++ b/tcp_splice.c
@@ -612,7 +612,7 @@ retry:
}
}
- break;
+ continue;
}
conn->read[fromsidei] += readlen > 0 ? readlen : 0;