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> --- Changes in v3: - Dropped changes to fill the vnet header. - Splitted patch "tun: Unify vnet implementation". - Reverted spurious changes in patch "tun: Unify vnet implementation". - Merged tun_vnet.c into TAP. - Link to v2: https://lore.kernel.org/r/20250109-tun-v2-0-388d7d5a287a@xxxxxxxxxx Changes in v2: - Fixed num_buffers endian. - Link to v1: https://lore.kernel.org/r/20250108-tun-v1-0-67d784b34374@xxxxxxxxxx --- Akihiko Odaki (9): tun: Refactor CONFIG_TUN_VNET_CROSS_LE tun: Avoid double-tracking iov_iter length changes tun: Keep hdr_len in tun_get_user() tun: Decouple vnet from tun_struct tun: Decouple vnet handling tun: Extract the vnet handling code tap: Avoid double-tracking iov_iter length changes tap: Keep hdr_len in tap_get_user() tap: Use tun's vnet-related code MAINTAINERS | 2 +- drivers/net/Kconfig | 1 + drivers/net/Makefile | 3 +- drivers/net/tap.c | 172 ++++++------------------------------------ drivers/net/tun.c | 200 +++++++------------------------------------------ drivers/net/tun_vnet.c | 180 ++++++++++++++++++++++++++++++++++++++++++++ drivers/net/tun_vnet.h | 25 +++++++ 7 files changed, 260 insertions(+), 323 deletions(-) --- base-commit: a32e14f8aef69b42826cf0998b068a43d486a9e9 change-id: 20241230-tun-66e10a49b0c7 Best regards, -- Akihiko Odaki <akihiko.odaki@xxxxxxxxxx>
