On Sat, Oct 24, 2026 at 02:45:39AM -0400, Michael S. Tsirkin wrote:
> Ah, no IFF_VNET_HDR *with* vhost. That's a weird combination.
>
> Apologies. TUN_VNET_TNL_SIZE is an internal macro that header size
> is set it. TUNSETVNETHDRSZ is what I meant.
>
> I have in mind simply disabling this combo: vhost + !IFF_VNET_HDR)
>
> I'll research a bit whether anything anywhere could reasonably
> use it.
>
> Can you reproduce any problem *with* IFF_VNET_HDR?
Yes. I added IFF_VNET_HDR + TUNSETVNETHDRSZ(24) to the repro
(in addition to VHOST_SET_FEATURES_ARRAY with the tunnel GSO bits
and VHOST_NET_F_VIRTIO_NET_HDR):
tap ifindex = 20482
TUNSETVNETHDRSZ(24) ok
tap attached to RX vq
--- RX buffer first 32 bytes (initially all 0xAA) ---
hdr: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa 00 00 00 00 00 00 00 00
The entire 24-byte vnet header area is stale 0xAA fill — including
offsets 0..9 where vhost is supposed to write the virtio_net_hdr.
The payload (from the host) starts at offset 24.
So the uninitialized vnet header is observable in both configurations:
with and without IFF_VNET_HDR on the tun device.
Note that with IFF_VNET_HDR enabled, the RX buffer is also corrupted
in a different way: the tun device prepends its own 24-byte vnet
header to the data it sends to vhost, and handle_rx() with
sock_hlen = 0 does not skip it. So even if the virtio_net_hdr
were properly written, the payload delivered to the guest would
be shifted by 24 bytes.
Best,
Guikun Yang
