From patchwork Wed Aug 7 17:55:03 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Sitnicki X-Patchwork-Id: 13756562 X-Patchwork-Delegate: kuba@kernel.org Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 04A7F13D25E for ; Wed, 7 Aug 2024 17:55:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.47 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723053325; cv=none; b=F3B+ifVMr1xSFg2qdRVn7/6JwTvopUE20rr1l2W8Zr87n6YyxOnP0RrRqgh0Xu6NTVvgmhCJ6N5Dhz9Q27qKKneVjrBSvoE+6EQq9AZMbCyItN5N5IoThY9NqesJVBLGuQRBSo+GSMNNmLBSSgBlbYS+t7O18bW6iC/UkxdL6p8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723053325; c=relaxed/simple; bh=HaEwFXksDi/dpM2Vlw0p5y2x3N5buakJ/EJUfn/tr8U=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Z+zYeuQRC328luG9SM+58NDHpsAK5eJ8zdG45nwY0KQQbtGJ7tVtdKCi0XF7QQ7MrbhA2SkCkHoot1axbOGKJn4iAvVrBk4wctRQSkSXOK8ToXstibHIJZiYUjDUsj2+6atQckBfl47GDosaYAz397c8R0WsJPNAUyrAa7vDCq4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com; spf=pass smtp.mailfrom=cloudflare.com; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b=N9AXgb5d; arc=none smtp.client-ip=209.85.208.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="N9AXgb5d" Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-5bb8e62570fso82932a12.1 for ; Wed, 07 Aug 2024 10:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1723053322; x=1723658122; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=79ak/F+8KlAbfdZYEbeWqf86QQ62ng9RoPRjUoCpeD8=; b=N9AXgb5dqGKsDbFHvutbliaiTs5yyZV5Kz4f+HOPvL7YYsNw0NCM+yjkdyoiQG8kWK kWclvIbBMSZhmwOhcQS2/BRnX2jhU9sWNs4f6xoUtsONWpxlWsWIa3BR1XlOyViPu6X/ JpbWoxU6Ji38lyZbfy8Jij/eB5DA1hRp/GZLHr7EaiGuVIK9pdvNmIEeOujym9awnzFh QzsXV+XcrIyJoYNPjAmrrbbHMZWOKVDUtZF0iV1z3sAGkoD7ucvm8FX1pwbGbC33Np1O 6eTDgxd4iGCHiGfF9Apu2c3WOObCXRPLtp39oC7c9diL6kxrZ/CFNO8Lu77pbQ5Xrwmg 9Qmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723053322; x=1723658122; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=79ak/F+8KlAbfdZYEbeWqf86QQ62ng9RoPRjUoCpeD8=; b=V7aS23DDkMW7EF9m2UXT3zs+cL8cK4jtARDsm8D9shuceGZxd+os9Y8dVaj3hOxb7x AsDi+GDcEBX1id2lNmdeo3HIOA98ugSZznqdT1SI+gSlPU6fJi1iOKt/tG97miqQKxVX Gi74y2lju5EH2DrIlcxLPmLhg8PDHi3sOX+mMGIgGoqrIhDq3cSejRYlHeLWuutFeaUE 3bzkE2f61F6T45u3QeaDKeWAimkWA/qsAjVR6VY1RkKMb3p9fdGrWCYpAn4KjBuI/aa6 nrIpeVkfR12xURLUbmAH2ghTsma8ZOpLuVcqGsjlLYE1lR/K9QNztLpGf4AkgJwhTpI3 feSA== X-Gm-Message-State: AOJu0YxwXkCFNMNErSKO/Dny9AN0MFEVqf29jU9aShVCvUB1tAM7IiHS ku8aiZld8ti1B2MWAIZlfPrHUs3p3Aq0GCQX+tYgLEAARJEiFvkqvHRWUkF0JnQCsASitnB6bS7 V X-Google-Smtp-Source: AGHT+IGL/D+Aw/TseYvGsEOgkIJocJ3XTdrutxyaAgKrHflxXvpi9XmTbP+VNCLDqqG+vdykEp7MLA== X-Received: by 2002:aa7:cd98:0:b0:5a3:8c9:3c1d with SMTP id 4fb4d7f45d1cf-5b7f3bcfc21mr13077844a12.14.1723053322070; Wed, 07 Aug 2024 10:55:22 -0700 (PDT) Received: from cloudflare.com ([2a09:bac5:5063:2387::38a:2f]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5b83bf3b99dsm7198710a12.91.2024.08.07.10.55.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Aug 2024 10:55:21 -0700 (PDT) From: Jakub Sitnicki Date: Wed, 07 Aug 2024 19:55:03 +0200 Subject: [PATCH net v3 1/3] net: Make USO depend on CSUM offload Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20240807-udp-gso-egress-from-tunnel-v3-1-8828d93c5b45@cloudflare.com> References: <20240807-udp-gso-egress-from-tunnel-v3-0-8828d93c5b45@cloudflare.com> In-Reply-To: <20240807-udp-gso-egress-from-tunnel-v3-0-8828d93c5b45@cloudflare.com> To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Willem de Bruijn , kernel-team@cloudflare.com, Jakub Sitnicki X-Mailer: b4 0.14.1 X-Patchwork-Delegate: kuba@kernel.org UDP segmentation offload inherently depends on checksum offload. It should not be possible to disable checksum offload while leaving USO enabled. Enforce this dependency in code. There is a single tx-udp-segmentation feature flag to indicate support for both IPv4/6, hence the devices wishing to support USO must offer checksum offload for both IP versions. Fixes: 83aa025f535f ("udp: add gso support to virtual devices") Suggested-by: Willem de Bruijn Signed-off-by: Jakub Sitnicki --- net/core/dev.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index 751d9b70e6ad..dfb12164b35d 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -9912,6 +9912,16 @@ static void netdev_sync_lower_features(struct net_device *upper, } } +#define IP_CSUM_MASK (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM) + +static bool has_ip_or_hw_csum(netdev_features_t features) +{ + bool ip_csum = (features & IP_CSUM_MASK) == IP_CSUM_MASK; + bool hw_csum = features & NETIF_F_HW_CSUM; + + return ip_csum || hw_csum; +} + static netdev_features_t netdev_fix_features(struct net_device *dev, netdev_features_t features) { @@ -9993,15 +10003,9 @@ static netdev_features_t netdev_fix_features(struct net_device *dev, features &= ~NETIF_F_LRO; } - if (features & NETIF_F_HW_TLS_TX) { - bool ip_csum = (features & (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM)) == - (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM); - bool hw_csum = features & NETIF_F_HW_CSUM; - - if (!ip_csum && !hw_csum) { - netdev_dbg(dev, "Dropping TLS TX HW offload feature since no CSUM feature.\n"); - features &= ~NETIF_F_HW_TLS_TX; - } + if ((features & NETIF_F_HW_TLS_TX) && !has_ip_or_hw_csum(features)) { + netdev_dbg(dev, "Dropping TLS TX HW offload feature since no CSUM feature.\n"); + features &= ~NETIF_F_HW_TLS_TX; } if ((features & NETIF_F_HW_TLS_RX) && !(features & NETIF_F_RXCSUM)) { @@ -10009,6 +10013,11 @@ static netdev_features_t netdev_fix_features(struct net_device *dev, features &= ~NETIF_F_HW_TLS_RX; } + if ((features & NETIF_F_GSO_UDP_L4) && !has_ip_or_hw_csum(features)) { + netdev_dbg(dev, "Dropping USO feature since no CSUM feature.\n"); + features &= ~NETIF_F_GSO_UDP_L4; + } + return features; } From patchwork Wed Aug 7 17:55:04 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Sitnicki X-Patchwork-Id: 13756563 X-Patchwork-Delegate: kuba@kernel.org Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4F1D13E025 for ; Wed, 7 Aug 2024 17:55:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723053327; cv=none; b=sDqKJq1URLhpfWRPiEWf5v0yTh2ZaU2dFxM/LXpajIsy5nFZ6gHKkjw/icfu+IbUBTPHqNXe1Gve27BpBoOO4RX00hjZ+ag+rDBTbdP34v7W5/Hic7nC2fH64ZJ8qu6GumLbNWpu5aRDbh9hJVpOIndacpQnPHevhq6jxAvSo1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723053327; c=relaxed/simple; bh=rOt1O09oy9mrPry+P9E1ZWO2ddvquKRMzbBHhJzM0Nc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Y86wI68tDekyCa67l3DQsd0k1PjqohXFzzKnCAE/+BH+92rJgBUaXcveF/7LSyWigmUZ0vf00egrBfJrCT0lwT/VqTiT0V24i3TMX9imQmf7WTBsLOZp/7aVbS7jifPylU0r9iE0sdF10221wHLVp9Y1aBPF+V/Ia4L2rWF8qzk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com; spf=pass smtp.mailfrom=cloudflare.com; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b=d3AY6XQd; arc=none smtp.client-ip=209.85.167.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="d3AY6XQd" Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-52f01ec08d6so86107e87.2 for ; Wed, 07 Aug 2024 10:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1723053324; x=1723658124; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=G/3D5w+q6MISOydg6FT3J9TTsflbSnxeBAtnGlJu6tA=; b=d3AY6XQdRa8luCbWzN7Cyt95qoDAIAm4ZXWB6kgnC2yPp4rQiG/S2SYkibc0eTyM8S jTYHa3kyUbp/2z3nUZDtG7xfbAP8x1o2UeSDdwdblg8kmAyqqTw897aNvLDkdNRRJgCK 3na7z03nsVic4P8tC9P45p5OS7WXDJWcPowpqoajIyBez8wWPFnJ7+mlhSVxeGdWCJlA ta0cStnChhmhURp/OelwJalEO6d5BrQCW5z39VxSg6yVO2UYL3cz7wpbrq2rFAn4mFPn qCNNjHhv+HozMoqi8uHySv++Y7axIeL9LtyFvmK01hmz6c7+9Z6cBITmPfwIivE38uSa kxBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723053324; x=1723658124; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=G/3D5w+q6MISOydg6FT3J9TTsflbSnxeBAtnGlJu6tA=; b=Q7jZ9oNN4+HnxmacjcgKizbD/5vLVCbbfSIMa1rZHC+G0qt7pZpWdHDTeucfICsYta FkWwixyfsIxImy2RHrqzbMc27qr7wbp79UvWW/sz5lG1tvQuPG2Ic9zuUXsbL/JZVqx9 kzoGQFnMJLN6nqs8s8SLVKA892YvrYwNj4UhmvfJC7jCOyALabrOTy3tOSmRWuqCV1t5 xQ5m3MoRoY8vFRufw1/UHmHg2uUK71lMkiYvsPIx1PUZ8ErKZ+hHbdtawuMfKvxgZvmg GzAPfK6aK5LyPM8TBuxyCov+M+2spcTnTGxqyXTNCxq60H2Cyi0UzCWuDHObiiYG+d24 MRqA== X-Gm-Message-State: AOJu0YyuLgIIb9umS3+ja1Elu9dfyo8RD+JX23wFBm9TTVmChutNv3ER UPD62vvque16b2DijpZCu2rNk4y4wMwAuUvlWKn9/6NdrM1moFlMj/nO+qFlFG8= X-Google-Smtp-Source: AGHT+IFKHK9Vdfwo3uD/Jo7ruamgE2JaOzaZNrf7jI6dLiZBko/hEtvPNK7rv/e4yST+LzwP2R4fmg== X-Received: by 2002:a05:6512:3b8c:b0:52f:44b:7d42 with SMTP id 2adb3069b0e04-530bb3b4340mr13647060e87.58.1723053324021; Wed, 07 Aug 2024 10:55:24 -0700 (PDT) Received: from cloudflare.com ([2a09:bac5:5063:2387::38a:2f]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5b839b2b556sm7201521a12.25.2024.08.07.10.55.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Aug 2024 10:55:23 -0700 (PDT) From: Jakub Sitnicki Date: Wed, 07 Aug 2024 19:55:04 +0200 Subject: [PATCH net v3 2/3] udp: Fall back to software USO if IPv6 extension headers are present Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20240807-udp-gso-egress-from-tunnel-v3-2-8828d93c5b45@cloudflare.com> References: <20240807-udp-gso-egress-from-tunnel-v3-0-8828d93c5b45@cloudflare.com> In-Reply-To: <20240807-udp-gso-egress-from-tunnel-v3-0-8828d93c5b45@cloudflare.com> To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Willem de Bruijn , kernel-team@cloudflare.com, Jakub Sitnicki , syzbot+e15b7e15b8a751a91d9a@syzkaller.appspotmail.com X-Mailer: b4 0.14.1 X-Patchwork-Delegate: kuba@kernel.org In commit 10154dbded6d ("udp: Allow GSO transmit from devices with no checksum offload") we have intentionally allowed UDP GSO packets marked CHECKSUM_NONE to pass to the GSO stack, so that they can be segmented and checksummed by a software fallback when the egress device lacks these features. What was not taken into consideration is that a CHECKSUM_NONE skb can be handed over to the GSO stack also when the egress device advertises the tx-udp-segmentation / NETIF_F_GSO_UDP_L4 feature. This will happen when there are IPv6 extension headers present, which we check for in __ip6_append_data(). Syzbot has discovered this scenario, producing a warning as below: ip6tnl0: caps=(0x00000006401d7869, 0x00000006401d7869) WARNING: CPU: 0 PID: 5112 at net/core/dev.c:3293 skb_warn_bad_offload+0x166/0x1a0 net/core/dev.c:3291 Modules linked in: CPU: 0 PID: 5112 Comm: syz-executor391 Not tainted 6.10.0-rc7-syzkaller-01603-g80ab5445da62 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:skb_warn_bad_offload+0x166/0x1a0 net/core/dev.c:3291 [...] Call Trace: __skb_gso_segment+0x3be/0x4c0 net/core/gso.c:127 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x585/0x1120 net/core/dev.c:3661 __dev_queue_xmit+0x17a4/0x3e90 net/core/dev.c:4415 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0xffa/0x1680 net/ipv6/ip6_output.c:137 ip6_finish_output+0x41e/0x810 net/ipv6/ip6_output.c:222 ip6_send_skb+0x112/0x230 net/ipv6/ip6_output.c:1958 udp_v6_send_skb+0xbf5/0x1870 net/ipv6/udp.c:1292 udpv6_sendmsg+0x23b3/0x3270 net/ipv6/udp.c:1588 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xef/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2585 ___sys_sendmsg net/socket.c:2639 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2725 __do_sys_sendmmsg net/socket.c:2754 [inline] __se_sys_sendmmsg net/socket.c:2751 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2751 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...] We are hitting the bad offload warning because when an egress device is capable of handling segmentation offload requested by skb_shinfo(skb)->gso_type, the chain of gso_segment callbacks won't produce any segment skbs and return NULL. See the skb_gso_ok() branch in {__udp,tcp,sctp}_gso_segment helpers. To fix it, force a fallback to software USO when processing a packet with IPv6 extension headers, since we don't know if these can checksummed by all devices which offer USO. Fixes: 10154dbded6d ("udp: Allow GSO transmit from devices with no checksum offload") Reported-by: syzbot+e15b7e15b8a751a91d9a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000e1609a061d5330ce@google.com/ Signed-off-by: Jakub Sitnicki Reviewed-by: Willem de Bruijn --- net/ipv4/udp_offload.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index bc8a9da750fe..b254a5dadfcf 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -282,6 +282,12 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb, skb_transport_header(gso_skb))) return ERR_PTR(-EINVAL); + /* We don't know if egress device can segment and checksum the packet + * when IPv6 extension headers are present. Fall back to software GSO. + */ + if (gso_skb->ip_summed != CHECKSUM_PARTIAL) + features &= ~(NETIF_F_GSO_UDP_L4 | NETIF_F_CSUM_MASK); + if (skb_gso_ok(gso_skb, features | NETIF_F_GSO_ROBUST)) { /* Packet is from an untrusted source, reset gso_segs. */ skb_shinfo(gso_skb)->gso_segs = DIV_ROUND_UP(gso_skb->len - sizeof(*uh), From patchwork Wed Aug 7 17:55:05 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Sitnicki X-Patchwork-Id: 13756564 X-Patchwork-Delegate: kuba@kernel.org Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D9EAC13D25E for ; Wed, 7 Aug 2024 17:55:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723053329; cv=none; b=Ja7nMYpVLd3lwA+W7IgV7O8mQDzUnVcU58suov1ZjbpweQyxYsE5sVQnVkflwweshPN7m+Ky+LxbrG8h+i3j5jB3mpmAGTrp6qE7CT2kyxQ+EXaY6xYZxjTvSv1KO67pj+K6TcQN5iRgpdY0GRe37CmmoLAfsnx1RzkUKErz6a0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723053329; c=relaxed/simple; bh=gWWdO5xBWX5tU7fXTnRIHBQdQkp9TESMBHiNigorEHA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Tm8JXmUsu03rhOcqPcabD6sCx7TVUPBYLc+aoPLm302MCwapkcRfVnQ5EInc7b9Ct4Pb9/4jnumUZqre4X9f37Rza1zfQOU6JqqhYbn4VSdw24rkQZlP4Zv9abl8de0yjb/DP+4aUli6BBAf0SNSAkWFhFIC+yiM21oUvkKF5Z4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com; spf=pass smtp.mailfrom=cloudflare.com; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b=b2m4bVA/; arc=none smtp.client-ip=209.85.218.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="b2m4bVA/" Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-a7ad02501c3so9242666b.2 for ; Wed, 07 Aug 2024 10:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1723053326; x=1723658126; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=W7D0AJSGl0P0jq0Bi/L5OZ1HP+papERMI7L86hsLZjQ=; b=b2m4bVA/D9r8LQT9EcdFGdYD40yAi/sKJvgwKIi5kkrSlZhr1C30bZoV3DNyRgOdmI O9CsQRxyn3/yxjyUlixgnqcM36wHWuKAa9dQa/2FLR0OuThgoEiLtkZ0sjQJlWMRMd56 d8yBdXd9dgWtAfi9qcp/ZY7w510XoRFx/r9sylShaTpgw9sgT0HBuVTwxKJmAhZNtRME g5UrDXQFyLtYf2oUgo0urXF9SsEnoGRWWj1eSJdlPiClKfoe0qH6n5atjfqU6sFQpOfP gcuZd3yHpfWWcvP1OP6TchIKXsCso/xLCqpYy3EQSkx/bZqATqe1VaW/nDcODC2pmxnZ 9u3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723053326; x=1723658126; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=W7D0AJSGl0P0jq0Bi/L5OZ1HP+papERMI7L86hsLZjQ=; b=nWuorZ4c0+6/Muw7qHaYDDasYa9bsQ/BDRIEWkYpSlKLZgOQdCdavweB/SBiFMb962 yZlqpvShvjFYv0Kj5XiyqXKJrR62dy294uAnio2s37MQRQKg0+Qf7jqPWKbxGCkk11Am su1Jv5Db+yL045uVK5Ismq83aRV5i2dh1FVmtwTtaOts4MgzkuPYUabX4TECYhptnFfM V5PCd6jTUvPmxXzGndbVIA4eGqy5ht0O5k37WMtijieL2Trq4z9K/lBhqdq4QyreMpuo eFa7TT4cNfWkzG8ml6A08tJhD8woNid273StCtacvrfjcf9nPweH3bP8iosOPj7qDnD/ hf7w== X-Gm-Message-State: AOJu0Yx22cTPghDtk5uGyMWEbocogohvS8yo+FiDQwdJO48Bn/ggaf/M OgluZppLnUuk/bMTSUMdknTRmEye6rm5eY4zTaJDPagmsLw/CCSv3hWBeXHjDvs= X-Google-Smtp-Source: AGHT+IHp2jgvISaG8pBADYmKzuKQNcKydtleGTpYCgyTjJfNufmaAx8m5p8j8hG/hltuTUKERtyeEw== X-Received: by 2002:a17:906:7315:b0:a7a:af5d:f314 with SMTP id a640c23a62f3a-a7dc51bd623mr1467070966b.63.1723053325937; Wed, 07 Aug 2024 10:55:25 -0700 (PDT) Received: from cloudflare.com ([2a09:bac5:5063:2387::38a:2f]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7dc9ecabb2sm654261966b.214.2024.08.07.10.55.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Aug 2024 10:55:25 -0700 (PDT) From: Jakub Sitnicki Date: Wed, 07 Aug 2024 19:55:05 +0200 Subject: [PATCH net v3 3/3] selftests/net: Add coverage for UDP GSO with IPv6 extension headers Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20240807-udp-gso-egress-from-tunnel-v3-3-8828d93c5b45@cloudflare.com> References: <20240807-udp-gso-egress-from-tunnel-v3-0-8828d93c5b45@cloudflare.com> In-Reply-To: <20240807-udp-gso-egress-from-tunnel-v3-0-8828d93c5b45@cloudflare.com> To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Willem de Bruijn , kernel-team@cloudflare.com, Jakub Sitnicki X-Mailer: b4 0.14.1 X-Patchwork-Delegate: kuba@kernel.org After enabling UDP GSO for devices not offering checksum offload, we have hit a regression where a bad offload warning can be triggered when sending a datagram with IPv6 extension headers. Extend the UDP GSO IPv6 tests to cover this scenario. Signed-off-by: Jakub Sitnicki Reviewed-by: Willem de Bruijn --- tools/testing/selftests/net/udpgso.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/udpgso.c b/tools/testing/selftests/net/udpgso.c index 3e74cfa1a2bf..3f2fca02fec5 100644 --- a/tools/testing/selftests/net/udpgso.c +++ b/tools/testing/selftests/net/udpgso.c @@ -67,6 +67,7 @@ struct testcase { int gso_len; /* mss after applying gso */ int r_num_mss; /* recv(): number of calls of full mss */ int r_len_last; /* recv(): size of last non-mss dgram, if any */ + bool v6_ext_hdr; /* send() dgrams with IPv6 extension headers */ }; const struct in6_addr addr6 = { @@ -77,6 +78,8 @@ const struct in_addr addr4 = { __constant_htonl(0x0a000001), /* 10.0.0.1 */ }; +static const char ipv6_hopopts_pad1[8] = { 0 }; + struct testcase testcases_v4[] = { { /* no GSO: send a single byte */ @@ -255,6 +258,13 @@ struct testcase testcases_v6[] = { .gso_len = 1, .r_num_mss = 2, }, + { + /* send 2 1B segments with extension headers */ + .tlen = 2, + .gso_len = 1, + .r_num_mss = 2, + .v6_ext_hdr = true, + }, { /* send 2B + 2B + 1B segments */ .tlen = 5, @@ -396,11 +406,18 @@ static void run_one(struct testcase *test, int fdt, int fdr, int i, ret, val, mss; bool sent; - fprintf(stderr, "ipv%d tx:%d gso:%d %s\n", + fprintf(stderr, "ipv%d tx:%d gso:%d %s%s\n", addr->sa_family == AF_INET ? 4 : 6, test->tlen, test->gso_len, + test->v6_ext_hdr ? "ext-hdr " : "", test->tfail ? "(fail)" : ""); + if (test->v6_ext_hdr) { + if (setsockopt(fdt, IPPROTO_IPV6, IPV6_HOPOPTS, + ipv6_hopopts_pad1, sizeof(ipv6_hopopts_pad1))) + error(1, errno, "setsockopt ipv6 hopopts"); + } + val = test->gso_len; if (cfg_do_setsockopt) { if (setsockopt(fdt, SOL_UDP, UDP_SEGMENT, &val, sizeof(val))) @@ -412,6 +429,12 @@ static void run_one(struct testcase *test, int fdt, int fdr, error(1, 0, "send succeeded while expecting failure"); if (!sent && !test->tfail) error(1, 0, "send failed while expecting success"); + + if (test->v6_ext_hdr) { + if (setsockopt(fdt, IPPROTO_IPV6, IPV6_HOPOPTS, NULL, 0)) + error(1, errno, "setsockopt ipv6 hopopts clear"); + } + if (!sent) return;