| Message ID | 20250109-tun-v2-0-388d7d5a287a@daynix.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | tun: Unify vnet implementation and fill full vnet header | expand |
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> > --- > Changes in v2: > - Fixed num_buffers endian. > - Link to v1: https://lore.kernel.org/r/20250108-tun-v1-0-67d784b34374@daynix.com > > --- > Akihiko Odaki (3): > tun: Unify vnet implementation > tun: Pad virtio header with zero > tun: Set num_buffers for virtio 1.0 Patches should explicitly to net or net-next. In this case if the undefined data would be a bug, that would target net. It sounds as if this is only relevant with the upcoming hash changes, so then it too can target net-next. If needed at all. The first patch is clearly net-next material. I would prefer to work on that independent from the rest. I'm in favor of deduplicating logic across tun/tap/pf_packet. Have taken a stab, but haven't gotten to a concrete series. This indeed a valid deduplication effort. We have to make sure that the code is identical between tun and tap, or where it isn't (due to one of the two having received a change to such code, but the other not) explicitly note that in the commit message. As then it is a behavioral change. Anyway, let's send the undefined data, hash and dedup changes independently. And preferably one after the other, rather than having concurrent conversations across threads.
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 v2: - Fixed num_buffers endian. - Link to v1: https://lore.kernel.org/r/20250108-tun-v1-0-67d784b34374@daynix.com --- Akihiko Odaki (3): tun: Unify vnet implementation tun: Pad virtio header with zero tun: Set num_buffers for virtio 1.0 MAINTAINERS | 1 + drivers/net/Kconfig | 5 ++ drivers/net/Makefile | 1 + drivers/net/tap.c | 174 ++++++---------------------------------- drivers/net/tun.c | 214 +++++++++---------------------------------------- drivers/net/tun_vnet.c | 191 +++++++++++++++++++++++++++++++++++++++++++ drivers/net/tun_vnet.h | 24 ++++++ 7 files changed, 283 insertions(+), 327 deletions(-) --- base-commit: a32e14f8aef69b42826cf0998b068a43d486a9e9 change-id: 20241230-tun-66e10a49b0c7 Best regards,