Re: [PATCH v2] tcp: Handle errors from tcp_send_flag()

On Thu, 23 Apr 2026 11:53:14 +0530 Anshu Kumari wrote:

tcp_send_flag() can fail in two different ways: - tcp_prepare_flags() returns -ECONNRESET when getsockopt(TCP_INFO) fails: the socket is broken and the connection must be reset. - tcp_vu_send_flag() returns -EAGAIN when vu_collect() finds no available vhost-user buffers: this is a transient condition equivalent to a dropped packet on the wire.

Have tcp_vu_send_flag() return -EAGAIN instead of a bare -1 for the buffer-unavailable case. Absorb -EAGAIN in the tcp_send_flag() dispatcher so that callers only see fatal errors.

Check the return value at each call site and handle fatal errors: - in tcp_data_from_tap(), return -1 so the caller resets - in tcp_tap_handler(), goto reset - in tcp_timer_handler()/tcp_sock_handler()/tcp_conn_from_sock_finish(), call tcp_rst() and return - in tcp_tap_conn_from_sock(), set CLOSING flag, call FLOW_ACTIVATE() to avoid leaving the flow in TYPED state, and return - in tcp_connect_finish(), call tcp_rst() and return - in tcp_keepalive(), call tcp_rst() and continue the loop - in tcp_flow_migrate_target_ext(), goto fail

The call in tcp_rst_do() is left unchecked: we are already resetting, and tcp_sock_rst() still needs to run regardless.

Link: https://bugs.passt.top/show_bug.cgi?id=194 Signed-off-by: Anshu Kumari --- v2: - updated commit message. - update tcp_vu_send_flag() to return -EAGAIN instead of -1 for buffer-unavailable case. - in tcp_tap_conn_from_sock(), added FLOW_ACTIVATE call. - inside tcp_send_flag(), updated the return statement. function will return 0 incase of -EAGAIN error.

Applied, thanks for the detailed change log! Just one detail: this had two trivial conflicts with commit 831857e9b547 ("tcp: Replace send buffer boost with EPOLLOUT monitoring") which I merged earlier this week (my Monday): $ git show -s --format=%cd 831857e9b547 Mon Apr 20 23:20:41 2026 +0200 I solved those on merge, and I usually do that if the resolution is obvious, but in general you should 'git pull --rebase' or similar (depending on how / whether you use branches) just before submitting patches, so that conflicts are less likely to happen. They might still happen if there are other pending patches that are then merged at the same time but that's unavoidable (and in general I'll just solve conflicts in that case because that's usually my fault for reviewing or merging things too late / slowly). -- Stefano