Linux Documentation
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	 Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	 Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	 Jason Wang <jasowang@redhat.com>,
	 "David S. Miller" <davem@davemloft.net>,
	 Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>,
	 Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
	 Shuah Khan <shuah@kernel.org>,
	 linux-doc@vger.kernel.org,  linux-kernel@vger.kernel.org,
	 netdev@vger.kernel.org,  kvm@vger.kernel.org,
	 virtualization@lists.linux-foundation.org,
	 linux-kselftest@vger.kernel.org,
	 Yuri Benditovich <yuri.benditovich@daynix.com>,
	 Andrew Melnychenko <andrew@daynix.com>,
	 Stephen Hemminger <stephen@networkplumber.org>,
	 gur.stavi@huawei.com,  devel@daynix.com
Subject: Re: [PATCH net v3 0/9] tun: Unify vnet implementation
Date: Thu, 16 Jan 2025 07:54:00 -0500	[thread overview]
Message-ID: <678901682ff09_3710bc2944f@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <20250116031331-mutt-send-email-mst@kernel.org>

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.

  reply	other threads:[~2025-01-16 12:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-16  8:08 [PATCH net v3 0/9] tun: Unify vnet implementation Akihiko Odaki
2025-01-16  8:08 ` [PATCH net v3 1/9] tun: Refactor CONFIG_TUN_VNET_CROSS_LE Akihiko Odaki
2025-01-17  9:57   ` Willem de Bruijn
2025-01-16  8:08 ` [PATCH net v3 2/9] tun: Avoid double-tracking iov_iter length changes Akihiko Odaki
2025-01-17 10:03   ` Willem de Bruijn
2025-01-16  8:08 ` [PATCH net v3 3/9] tun: Keep hdr_len in tun_get_user() Akihiko Odaki
2025-01-17 10:17   ` Willem de Bruijn
2025-01-16  8:08 ` [PATCH net v3 4/9] tun: Decouple vnet from tun_struct Akihiko Odaki
2025-01-17  9:16   ` Willem de Bruijn
2025-01-17 10:28     ` Willem de Bruijn
2025-01-16  8:08 ` [PATCH net v3 5/9] tun: Decouple vnet handling Akihiko Odaki
2025-01-17  9:18   ` Willem de Bruijn
2025-01-16  8:08 ` [PATCH net v3 6/9] tun: Extract the vnet handling code Akihiko Odaki
2025-01-17 10:42   ` Willem de Bruijn
2025-01-16  8:08 ` [PATCH net v3 7/9] tap: Avoid double-tracking iov_iter length changes Akihiko Odaki
2025-01-16  8:08 ` [PATCH net v3 8/9] tap: Keep hdr_len in tap_get_user() Akihiko Odaki
2025-01-16  8:08 ` [PATCH net v3 9/9] tap: Use tun's vnet-related code Akihiko Odaki
2025-01-17  9:23   ` Willem de Bruijn
2025-01-17 10:35     ` Akihiko Odaki
2025-01-20  0:36       ` Jason Wang
2025-01-20 11:19         ` Willem de Bruijn
2025-01-21  5:27           ` Akihiko Odaki
2025-01-21 14:44             ` Willem de Bruijn
2025-01-16  8:14 ` [PATCH net v3 0/9] tun: Unify vnet implementation Michael S. Tsirkin
2025-01-16 12:54   ` Willem de Bruijn [this message]
2025-01-17  6:50     ` Akihiko Odaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=678901682ff09_3710bc2944f@willemb.c.googlers.com.notmuch \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=akihiko.odaki@daynix.com \
    --cc=andrew@daynix.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=devel@daynix.com \
    --cc=edumazet@google.com \
    --cc=gur.stavi@huawei.com \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    --cc=stephen@networkplumber.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xuanzhuo@linux.alibaba.com \
    --cc=yuri.benditovich@daynix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox