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.
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.