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

[Stefano Brivio <sbrivio@redhat.com>]

On Thu, 23 Apr 2026 11:53:14 +0530
Anshu Kumari <anskuma@redhat.com> 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 <anskuma@redhat.com>
> ---
> 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