| Message ID | 20250116-tun-v3-0-c6b2871e97f7@daynix.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | tun: Unify vnet implementation | expand |
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@daynix.com > [2]: https://lore.kernel.org/r/20241227084256-mutt-send-email-mst@kernel.org/ > > Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Will review. But this does not look like net material to me. Not really a bugfix. More like net-next. > --- > 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@daynix.com > > Changes in v2: > - Fixed num_buffers endian. > - Link to v1: https://lore.kernel.org/r/20250108-tun-v1-0-67d784b34374@daynix.com > > --- > 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@daynix.com>
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@daynix.com > > [2]: https://lore.kernel.org/r/20241227084256-mutt-send-email-mst@kernel.org/ > > > > Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> > > 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.
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 [2]: https://lore.kernel.org/r/20241227084256-mutt-send-email-mst@kernel.org/ Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> --- 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@daynix.com Changes in v2: - Fixed num_buffers endian. - Link to v1: https://lore.kernel.org/r/20250108-tun-v1-0-67d784b34374@daynix.com --- 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,