On Thu, Feb 20, 2025 at 4:45 PM Michael S. Tsirkin <m...@redhat.com> wrote: > > On Thu, Feb 20, 2025 at 08:58:38AM +0100, Paolo Abeni wrote: > > Hi, > > > > On 2/15/25 7:04 AM, Akihiko Odaki wrote: > > > tun simply advances iov_iter when it needs to pad virtio header, > > > which leaves the garbage in the buffer as is. This will become > > > especially problematic when tun starts to allow enabling the hash > > > reporting feature; even if the feature is enabled, the packet may lack a > > > hash value and may contain a hole in the virtio header because the > > > packet arrived before the feature gets enabled or does not contain the > > > header fields to be hashed. If the hole is not filled with zero, it is > > > impossible to tell if the packet lacks a hash value. > > > > Should virtio starting sending packets only after feature negotiation? > > In other words, can the above happen without another bug somewhere else? > > > Not if this is connected with a guest with the standard virtio driver, no. > The issue is that tun has no concept of feature negotiation, > and we don't know who uses the vnet header feature, or why. > > > I guess the following question is mostly for Jason and Michael: could be > > possible (/would it make any sense) to use a virtio_net_hdr `flags` bit > > to explicitly signal the hash fields presence? i.e. making the actual > > virtio_net_hdr size 'dynamic'. > > But it is dynamic - that is why we have TUNSETVNETHDRSZ.
Yes, tun currently only recognizes a subset of the whole virtio-net header. Thanks
