Michael S. Tsirkin wrote:

On Thu, Jan 16, 2025 at 05:08:03PM +0900, Akihiko Odaki wrote:

quoted

When I implemented virtio's hash-related features to tun/tap [1],
I found tun/tap does not fill the entire region reserved for the virtio
header, leaving some uninitialized hole in the middle of the buffer
after read()/recvmesg().

This series fills the uninitialized hole. More concretely, the
num_buffers field will be initialized with 1, and the other fields will
be inialized with 0. Setting the num_buffers field to 1 is mandated by
virtio 1.0 [2].

The change to virtio header is preceded by another change that refactors
tun and tap to unify their virtio-related code.

[1]: https://lore.kernel.org/r/20241008-rss-v5-0-f3cf68df005d@daynix.com (local)
[2]: https://lore.kernel.org/r/20241227084256-mutt-send-email-mst@kernel.org/ (local)

Signed-off-by: Akihiko Odaki <redacted>

Will review. But this does not look like net material to me.
Not really a bugfix. More like net-next.

+1. I said basically the same in v2.

Perhaps the field initialization is net material, though not
critical until hashing is merged, so not stable.

The deduplication does not belong in net.

IMHO it should all go to net-next.