Michael S. Tsirkin wrote: > On Thu, Jan 16, 2025 at 05:08:03PM +0900, Akihiko Odaki wrote: > > 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@xxxxxxxxxx > > [2]: https://lore.kernel.org/r/20241227084256-mutt-send-email-mst@xxxxxxxxxx/ > > > > Signed-off-by: Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> > > 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.
