passt/tcp_vu.c, branch 2026_05_07.1afd4ed

tcp: Handle errors from tcp_send_flag()

2026-04-24T21:35:43+00:00

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 
Signed-off-by: Stefano Brivio

treewide: Spell ASSERT() as assert()

2026-03-20T20:05:29+00:00

The standard library assert(3), at least with glibc, hits our seccomp
filter and dies with SIGSYS before it's able to print a message, making it
near useless.  Therefore, since 7a8ed9459dfe ("Make assertions actually
useful") we've instead used our own implementation, named ASSERT().

This makes our code look slightly odd though - ASSERT() has the same
overall effect as assert(), it's just a different implementation.  More
importantly this makes it awkward to share code between passt/pasta proper
and things that compile in a more typical environment.  We're going to want
that for our upcoming dynamic configuration tool.

Address this by overriding the standard library's assert() implementation
with our own, instead of giving ours its own name.

The standard assert() is supposed to be omitted if NDEBUG is defined,
which ours doesn't do.  Implement that as well, so ours doesn't
unexpectedly differ.  For the -DNDEBUG case we do this by *not* overriding
assert(), since it will be a no-op anyway.  This requires a few places to
add a #include  to let us compile (albeit with warnings) when
-DNDEBUG.

Signed-off-by: David Gibson 
[sbrivio: Fix some conflicts and missing conversions as a result of
 applying "vu_common: Move iovec management into vu_collect()" first]
Signed-off-by: Stefano Brivio

vu_common: Move iovec management into vu_collect()

2026-03-20T19:05:34+00:00

Previously, callers had to pre-initialize virtqueue elements with iovec
entries using vu_set_element() or vu_init_elem() before calling
vu_collect().  This meant each element owned a fixed, pre-assigned iovec
slot.

Move the iovec array into vu_collect() as explicit parameters (in_sg,
max_in_sg, and in_total), letting it pass the remaining iovec capacity
directly to vu_queue_pop().  A running current_iov counter tracks
consumed entries across elements, so multiple elements share a single
iovec pool.  The optional in_total output parameter reports how many iovec
entries were consumed, allowing callers to track usage across multiple
vu_collect() calls.

This removes vu_set_element() and vu_init_elem() which are no longer
needed, and is a prerequisite for multi-buffer support where a single
virtqueue element can use more than one iovec entry.  For now, callers
assert the current single-iovec-per-element invariant until they are
updated to handle multiple iovecs.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

iov: Add iov_truncate() helper and use it in vu handlers

2026-03-10T14:26:43+00:00

Add a generic iov_truncate() function that truncates an IO vector to a
given number of bytes, returning the number of iov entries that contain
data after truncation.

Use it in udp_vu_sock_recv() and tcp_vu_sock_recv() to replace the
open-coded truncation logic that adjusted iov entries after recvmsg().
Also convert the direct iov_len assignment in tcp_vu_send_flag() to use
iov_truncate() for consistency.

Add an ASSERT() in tcp_vu_data_from_sock() to quiet the Coverity error:

passt/tcp_vu.c:457:3:
  19. overflow_const: Expression "dlen + hdrlen", where "dlen" is known to
      be equal to -86,  and "hdrlen" is known to be equal to 86, underflows
      the type of "dlen + hdrlen", which is type "unsigned long".

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

vu_common: Always set num_buffers in virtio-net header

2026-03-04T17:50:49+00:00

Legacy virtio used two different header formats: struct virtio_net_hdr
(10 bytes) when VIRTIO_NET_F_MRG_RXBUF was not negotiated, and
struct virtio_net_hdr_mrg_rxbuf (12 bytes) when it was.  The
num_buffers field only existed in the larger header.

Modern virtio (VIRTIO_F_VERSION_1, i.e. virtio 1.0+) always uses the
12-byte struct virtio_net_hdr_mrg_rxbuf header regardless of whether
VIRTIO_NET_F_MRG_RXBUF is negotiated, so num_buffers is always present
in the header.  passt only supports modern virtio and dies if
VIRTIO_F_VERSION_1 is not negotiated (vhost_user.c), and VNET_HLEN is
unconditionally defined as sizeof(struct virtio_net_hdr_mrg_rxbuf).

The virtio specification (v1.1, section 5.1.6) requires that:

  "The device MUST set num_buffers to 1 if VIRTIO_NET_F_MRG_RXBUF has
   not been negotiated."

vu_set_vnethdr() only set num_buffers when VIRTIO_NET_F_MRG_RXBUF was
negotiated.  When it was not, num_buffers was left uninitialised,
violating the spec.

Since vu_collect() already limits buffer collection to a single element
when VIRTIO_NET_F_MRG_RXBUF is not negotiated, num_buffers passed by
callers is guaranteed to be 1 in that case.  We can therefore
unconditionally set num_buffers, which makes the vdev parameter
unnecessary.

Drop the vdev parameter from vu_set_vnethdr() and update all callers.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

tcp: Extend tcp_send_flag() to send TCP keepalive segments

2026-02-24T23:17:41+00:00

TCP keepalives aren't technically a flag, but they are a zero-data segment
so they can be generated with only a small modification to
tcp_{buf,vu}_send_flag().  Implement this, using a new "pseudo-flag"
value (similar to DUP_ACK), KEEPALIVE.

Signed-off-by: David Gibson 
[sbrivio: Fix trivial merge conflict with 812cdb802c6e]
Signed-off-by: Stefano Brivio

tcp_vu, udp_vu: Fix comment headers for header length functions

2026-02-24T15:31:29+00:00

The comment headers for tcp_vu_hdrlen() and udp_vu_hdrlen() described
the return value as "the size of the header in level 2 frame", but
these functions also include the virtio net header, which is not part
of the L2 frame.

Signed-off-by: Laurent Vivier 
[sbrivio: Rephrased comments a bit further]
Signed-off-by: Stefano Brivio

tcp_vu, udp_vu: Account for virtio net header in minimum frame size

2026-02-24T11:06:03+00:00

In the vhost-user paths, the buffers provided by the virtio queue
include the virtio net header (VNET_HLEN) prepended to the Ethernet
frame. The minimum size checks using ETH_ZLEN must therefore account
for this additional header length, otherwise we underestimate the
minimum buffer size needed.

Use ETH_ZLEN + VNET_HLEN instead of bare ETH_ZLEN in vu_collect()
calls and the corresponding ASSERT() checks.

In tcp_vu_prepare(), revert the ASSERT to just check for hdrlen,
because at that point iov[0].iov_len has been trimmed to the actual
received data size plus headers.

Fixes: 0cb8f9003654 ("tcp, udp: Pad batched frames for vhost-user modes to 60 bytes (802.3 minimum)")
Signed-off-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

tcp_vu: vu_pad() expects l2 length

2026-02-24T11:05:58+00:00

tcp_vu_hdrlen() returns a length that includes VNET_HLEN (the virtio
net header), but vu_pad() expects the Layer-2 frame length, which
should not include the virtio header. Passing the inflated length
means short frames aren't padded to the minimum 60-byte Ethernet
frame size (ETH_ZLEN).

Subtract VNET_HLEN from hdrlen when computing the l2 length passed
to vu_pad() in both tcp_vu_send_flag() and tcp_vu_data_from_sock().

Fixes: 0cb8f9003654 ("tcp, udp: Pad batched frames for vhost-user modes to 60 bytes (802.3 minimum)")
Signed-off-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

virtio: Introduce VNET_HLEN macro for virtio net header length

2026-02-15T01:52:51+00:00

Replace all open-coded sizeof(struct virtio_net_hdr_mrg_rxbuf) with a
VNET_HLEN macro.

Signed-off-by: Laurent Vivier 
Signed-off-by: Stefano Brivio