From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Akihiko Odaki <akihiko.odaki@daynix.com>,
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>,
"Michael S. Tsirkin" <mst@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,
Akihiko Odaki <akihiko.odaki@daynix.com>
Subject: Re: [PATCH v2 1/3] tun: Unify vnet implementation
Date: Thu, 09 Jan 2025 09:06:10 -0500 [thread overview]
Message-ID: <677fd7d26e090_362bc129432@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <20250109-tun-v2-1-388d7d5a287a@daynix.com>
Akihiko Odaki wrote:
> Both tun and tap exposes the same set of virtio-net-related features.
> Unify their implementations to ease future changes.
>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
> MAINTAINERS | 1 +
> drivers/net/Kconfig | 5 ++
> drivers/net/Makefile | 1 +
> drivers/net/tap.c | 172 ++++++----------------------------------
> drivers/net/tun.c | 208 ++++++++-----------------------------------------
> drivers/net/tun_vnet.c | 186 +++++++++++++++++++++++++++++++++++++++++++
> drivers/net/tun_vnet.h | 24 ++++++
> 7 files changed, 273 insertions(+), 324 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 910305c11e8a..1be8a452d11f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23903,6 +23903,7 @@ F: Documentation/networking/tuntap.rst
> F: arch/um/os-Linux/drivers/
> F: drivers/net/tap.c
> F: drivers/net/tun.c
> +F: drivers/net/tun_vnet.h
>
> TURBOCHANNEL SUBSYSTEM
> M: "Maciej W. Rozycki" <macro@orcam.me.uk>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 1fd5acdc73c6..255c8f9f1d7c 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -395,6 +395,7 @@ config TUN
> tristate "Universal TUN/TAP device driver support"
> depends on INET
> select CRC32
> + select TUN_VNET
No need for this new Kconfig
> static struct proto tap_proto = {
> .name = "tap",
> @@ -641,10 +576,10 @@ static ssize_t tap_get_user(struct tap_queue *q, void *msg_control,
> struct sk_buff *skb;
> struct tap_dev *tap;
> unsigned long total_len = iov_iter_count(from);
> - unsigned long len = total_len;
> + unsigned long len;
> int err;
> struct virtio_net_hdr vnet_hdr = { 0 };
> - int vnet_hdr_len = 0;
> + int hdr_len;
> int copylen = 0;
> int depth;
> bool zerocopy = false;
> @@ -652,38 +587,20 @@ static ssize_t tap_get_user(struct tap_queue *q, void *msg_control,
> enum skb_drop_reason drop_reason;
>
> if (q->flags & IFF_VNET_HDR) {
> - vnet_hdr_len = READ_ONCE(q->vnet_hdr_sz);
> -
> - err = -EINVAL;
> - if (len < vnet_hdr_len)
> - goto err;
> - len -= vnet_hdr_len;
> -
> - err = -EFAULT;
> - if (!copy_from_iter_full(&vnet_hdr, sizeof(vnet_hdr), from))
> - goto err;
> - iov_iter_advance(from, vnet_hdr_len - sizeof(vnet_hdr));
> - if ((vnet_hdr.flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) &&
> - tap16_to_cpu(q, vnet_hdr.csum_start) +
> - tap16_to_cpu(q, vnet_hdr.csum_offset) + 2 >
> - tap16_to_cpu(q, vnet_hdr.hdr_len))
> - vnet_hdr.hdr_len = cpu_to_tap16(q,
> - tap16_to_cpu(q, vnet_hdr.csum_start) +
> - tap16_to_cpu(q, vnet_hdr.csum_offset) + 2);
> - err = -EINVAL;
> - if (tap16_to_cpu(q, vnet_hdr.hdr_len) > len)
> + hdr_len = tun_vnet_hdr_get(READ_ONCE(q->vnet_hdr_sz), q->flags, from, &vnet_hdr);
> + if (hdr_len < 0) {
> + err = hdr_len;
> goto err;
> + }
> + } else {
> + hdr_len = 0;
> }
>
> - err = -EINVAL;
> - if (unlikely(len < ETH_HLEN))
> - goto err;
> -
Is this check removal intentional?
> + len = iov_iter_count(from);
> if (msg_control && sock_flag(&q->sk, SOCK_ZEROCOPY)) {
> struct iov_iter i;
>
> - copylen = vnet_hdr.hdr_len ?
> - tap16_to_cpu(q, vnet_hdr.hdr_len) : GOODCOPY_LEN;
> + copylen = hdr_len ? hdr_len : GOODCOPY_LEN;
> if (copylen > good_linear)
> copylen = good_linear;
> else if (copylen < ETH_HLEN)
> @@ -697,7 +614,7 @@ static ssize_t tap_get_user(struct tap_queue *q, void *msg_control,
>
> if (!zerocopy) {
> copylen = len;
> - linear = tap16_to_cpu(q, vnet_hdr.hdr_len);
> + linear = hdr_len;
> if (linear > good_linear)
> linear = good_linear;
> else if (linear < ETH_HLEN)
> @@ -732,9 +649,8 @@ static ssize_t tap_get_user(struct tap_queue *q, void *msg_control,
> }
> skb->dev = tap->dev;
>
> - if (vnet_hdr_len) {
> - err = virtio_net_hdr_to_skb(skb, &vnet_hdr,
> - tap_is_little_endian(q));
> + if (q->flags & IFF_VNET_HDR) {
> + err = tun_vnet_hdr_to_skb(q->flags, skb, &vnet_hdr);
> if (err) {
> rcu_read_unlock();
> drop_reason = SKB_DROP_REASON_DEV_HDR;
> @@ -797,23 +713,17 @@ static ssize_t tap_put_user(struct tap_queue *q,
> int total;
>
> if (q->flags & IFF_VNET_HDR) {
> - int vlan_hlen = skb_vlan_tag_present(skb) ? VLAN_HLEN : 0;
> struct virtio_net_hdr vnet_hdr;
>
> vnet_hdr_len = READ_ONCE(q->vnet_hdr_sz);
> - if (iov_iter_count(iter) < vnet_hdr_len)
> - return -EINVAL;
> -
> - if (virtio_net_hdr_from_skb(skb, &vnet_hdr,
> - tap_is_little_endian(q), true,
> - vlan_hlen))
> - BUG();
>
> - if (copy_to_iter(&vnet_hdr, sizeof(vnet_hdr), iter) !=
> - sizeof(vnet_hdr))
> - return -EFAULT;
> + ret = tun_vnet_hdr_from_skb(q->flags, NULL, skb, &vnet_hdr);
> + if (ret < 0)
> + goto done;
>
> - iov_iter_advance(iter, vnet_hdr_len - sizeof(vnet_hdr));
> + ret = tun_vnet_hdr_put(vnet_hdr_len, iter, &vnet_hdr);
> + if (ret < 0)
> + goto done;
Please split this patch in to a series of smaller patches.
If feasible:
1. one that move the head of tun.c into tun_vnet.[hc].
2. then one that uses that also in tap.c.
3. then a separate patch for the ioctl changes.
4. then introduce tun_vnet_hdr_from_skb, tun_vnet_hdr_put
and friends in (a) follow-up patch(es).
This is subtle code. Please report what tests you ran to ensure
that it does not introduce behavioral changes / regressions.
next prev parent reply other threads:[~2025-01-09 14:06 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 6:58 [PATCH v2 0/3] tun: Unify vnet implementation and fill full vnet header Akihiko Odaki
2025-01-09 6:58 ` [PATCH v2 1/3] tun: Unify vnet implementation Akihiko Odaki
2025-01-09 14:06 ` Willem de Bruijn [this message]
2025-01-10 8:28 ` Akihiko Odaki
2025-01-10 3:24 ` Jason Wang
2025-01-09 6:58 ` [PATCH v2 2/3] tun: Pad virtio header with zero Akihiko Odaki
2025-01-09 7:31 ` Michael S. Tsirkin
2025-01-09 7:41 ` Akihiko Odaki
2025-01-09 7:43 ` Michael S. Tsirkin
2025-01-09 9:36 ` Akihiko Odaki
2025-01-09 10:37 ` Jan Kara
2025-01-09 12:46 ` Willem de Bruijn
2025-01-10 4:38 ` Akihiko Odaki
2025-01-10 8:33 ` Michael S. Tsirkin
2025-01-10 10:45 ` Akihiko Odaki
2025-01-10 11:32 ` Willem de Bruijn
2025-01-09 7:42 ` Michael S. Tsirkin
2025-01-10 3:27 ` Jason Wang
2025-01-10 10:25 ` Akihiko Odaki
2025-01-09 6:58 ` [PATCH v2 3/3] tun: Set num_buffers for virtio 1.0 Akihiko Odaki
2025-01-09 7:32 ` Michael S. Tsirkin
2025-01-09 7:40 ` Michael S. Tsirkin
2025-01-09 9:38 ` Akihiko Odaki
2025-01-09 10:54 ` Michael S. Tsirkin
2025-01-09 11:10 ` Akihiko Odaki
2025-01-10 3:27 ` Jason Wang
2025-01-10 10:04 ` Akihiko Odaki
2025-01-10 10:23 ` Michael S. Tsirkin
2025-01-10 11:12 ` Akihiko Odaki
2025-01-13 3:04 ` Jason Wang
2025-01-15 5:07 ` Akihiko Odaki
2025-01-16 1:06 ` Jason Wang
2025-01-16 5:30 ` Akihiko Odaki
2025-01-20 0:40 ` Jason Wang
2025-01-20 4:57 ` Akihiko Odaki
2025-01-09 13:46 ` [PATCH v2 0/3] tun: Unify vnet implementation and fill full vnet header Willem de Bruijn
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=677fd7d26e090_362bc129432@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