Re: [PATCH] vhost/net: initialize the whole negotiated RX vnet header

[Guikun Yang <yangguikun19@qq.com>]

On Fri, Oct 23, 2026 at 08:13:22AM -0400, Michael S. Tsirkin wrote:
> Which backend did you use? Sounds like you did not set
> TUN_VNET_TNL_SIZE or did not set TUNSETOFFLOAD?
> That's the issue then.

The backend is a tap device attached via the normal tun path:
TUNSETIFF (IFF_TAP|IFF_NO_PI, no IFF_VNET_HDR), then
VHOST_NET_SET_BACKEND on the RX vq.

I re-ran the repro with TUNSETOFFLOAD declared before attaching the
backend, listing every offload bit the interface understands:

	TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
	TUN_F_USO4 | TUN_F_USO6 |
	TUN_F_UDP_TUNNEL_GSO | TUN_F_UDP_TUNNEL_GSO_CSUM

TUNSETOFFLOAD succeeds (0 is returned, so tun accepted all of them,
including the UDP tunnel GSO bits).  The result is unchanged:

	features[0] = 0x108000000, features[1] = 0xa   (tunnel bits on)
	VHOST_SET_FEATURES_ARRAY ok
	TUNSETOFFLOAD ok
	--- RX buffer first 32 bytes (initially all 0xAA) ---
	hdr: 00 00 00 00 00 00 00 00 00 00 01 00
	     aa aa aa aa aa aa aa aa aa aa aa aa     <-- offsets 12..23
	     33 33 00 00 ...

Offsets 12..23 still contain the stale 0xAA fill.

The reason is that vhost_net_set_features() computes vhost_hlen purely
from the feature bits passed via VHOST_SET_FEATURES(_ARRAY):

	hdr_len = ... sizeof(struct virtio_net_hdr_v1_hash_tunnel) when
	           HOST/GUEST_UDP_TUNNEL_GSO is set ...
	if (test_bit(VHOST_NET_F_VIRTIO_NET_HDR))
		vhost_hlen = hdr_len;

TUNSETOFFLOAD only updates tun->set_features and the tap device's
wanted_features; it does not feed back into the vhost feature bits or
into vhost_hlen.  handle_rx() then writes vhost_hlen bytes of the
virtio-net header into the guest buffer while handle_tx() / the GSO
path never touches those 12 bytes for a header vhost itself built.

I could not find TUN_VNET_TNL_SIZE anywhere in 7.3.0-rc7 or in
linux-next (drivers/net/tun.c, drivers/vhost/net.c, include/uapi/linux/
if_tun.h, include/uapi/linux/vhost.h) — is that an interface from a
tree/series I'm missing?  If it is meant to gate vhost_hlen I'd be
happy to re-test with it.

Meanwhile the stale 12 bytes are observable with a plain tun backend
that has declared full tunnel offload support, so I believe the patch
(Zero-initialize the largest header layout and copy vhost_hlen bytes)
is still needed.  Happy to re-test under whatever backend setup you
had in mind.

Best,
Guikun Yang