From patchwork Thu Aug 1 13:52:53 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Sitnicki X-Patchwork-Id: 13750554 X-Patchwork-Delegate: kuba@kernel.org Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (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 AEECF194AE6 for ; Thu, 1 Aug 2024 13:53:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722520402; cv=none; b=nYCzHqYN3oS7Sguiqdpjibhy01csjB5uc3tSSDgh+v74iU8YKGta+gXS4XM8TOwp0YvvBE6Kgcvo4DF1gIrVlWaf1C6zDcPYIEw9TtLnh3CvmNbznp5Wvk3L+tEbo5/zSOth1kCwL1KZDZJJyXFZzpP4t1636oQ42yMUTdqTOUU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722520402; c=relaxed/simple; bh=SzXUe9yAHmRgo7R6pFkuKRFs9oyR/775MYH5D1wNDRI=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=G//DT6CgFM+GH8iCEUd3yP+YrPBqJKhBikl8ymk/dqM0mPTNRpTDk9K0x8+feIY6hOlmro9tcqcE+N1+8chkCwftQDr7OKMqEWaLh7nKMKQJHGIo4OcpRbJcQLqoEYIcb9s4jHxXjwJ/yzoFPqyn6U3NF/wJxa8oUZXwWg0YILE= 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=WdHaLOW7; arc=none smtp.client-ip=209.85.218.49 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="WdHaLOW7" Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a7abe5aa9d5so806763566b.1 for ; Thu, 01 Aug 2024 06:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1722520399; x=1723125199; 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=PRqZUS14/M2IUp/ORafbn7y9pJ1mE6Kn31Q6JnF0XB4=; b=WdHaLOW7gQ6Oq4wmrY8BX4zwUjnhBZr5PQpYE5YL5zCXp4B/V0kkjduacUmNqPPlUW QqgnYURRx35d3+0bfXi5HN6BSHKOA7UZmij3NexdOoqSijjKWRK8WG/7L2v1sF0uDy6f 6qRWrk4LczREs8up7tmxb+qxcd0ZfKJ35muzrBpgNuGcqRr8K+DiBSnSDhoi+6I8FlOO 99hKX4HYOo4bsFUist01eggSQxkIUBIUvRBBpvCTSEOWA0NDv+X6i2P2usWKI2NtsOLQ XC4zVk9Y/dEmN4bERDN6OVD0Q8SikgzC7Ksc0mSowSuR3irTAumdkJPLaPSAf97rpef9 xHhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722520399; x=1723125199; 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=PRqZUS14/M2IUp/ORafbn7y9pJ1mE6Kn31Q6JnF0XB4=; b=A5SBW7N1AaZuLG3jptdMVT48bxGlm6QMVQOkbB7Gyhve25fY7exdHKvZL6qYKaXZd0 LxeN2GV4dBIuNHf+7fqbMO/8NRxvaZ7pjG6xr1AJjrEZM7K7lAvlLQ0oUKYtgEoEIDAy EtS48AWQBnHLSjw/qOtedxCJKoU8r2Xfm8FI6Xf8GWEG6fuaOLG0z0hNJl4d51R3xcpb hDih/TDwLfqaU2tYsHlJ8rM9UD4t3CDqlcI0GPSSv2mk6OGCM5Z3unWITfY5cmAPVuxQ AzMgoUbbueWcOHJbsHdjIo/O9+J4GNHNXRqWF1ymqakA8KDpxxvKZ95qGn14Kj6dligv NtLQ== X-Gm-Message-State: AOJu0YwjdZqCSf53y2fvQjyd+mQiqy539JDCTe230kme48a7iBFzTFDc sjPuMuoYkGZfUNnVmiHL74ii+vMmL2RiAz87kOkUH0jkAdCC5DahCTgaMUiBbG8= X-Google-Smtp-Source: AGHT+IFC8Nt7IdS9cyoElbCQwGvfqOu+K9/Hg/CKYM+cshFxLEB7Ldcn08ebwoCELzG18lHcQbgaiw== X-Received: by 2002:a17:907:1b10:b0:a7d:3ab9:6a5d with SMTP id a640c23a62f3a-a7dc5130c90mr14692966b.69.1722520399066; Thu, 01 Aug 2024 06:53:19 -0700 (PDT) Received: from cloudflare.com ([2a09:bac5:5063:2387::38a:2f]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7acab23d56sm902897166b.38.2024.08.01.06.53.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Aug 2024 06:53:18 -0700 (PDT) From: Jakub Sitnicki Date: Thu, 01 Aug 2024 15:52:53 +0200 Subject: [PATCH net v2 1/2] gso: Skip bad offload detection when device supports requested GSO Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20240801-udp-gso-egress-from-tunnel-v2-1-9a2af2f15d8d@cloudflare.com> References: <20240801-udp-gso-egress-from-tunnel-v2-0-9a2af2f15d8d@cloudflare.com> In-Reply-To: <20240801-udp-gso-egress-from-tunnel-v2-0-9a2af2f15d8d@cloudflare.com> To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Willem de Bruijn , kernel-team@cloudflare.com, 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 can happen in two situations, which we detect in __ip_append_data() and __ip6_append_data(): 1) when there are IPv6 extension headers present, or 2) when the tunnel device does not advertise checksum offload. Note that in the latter case we have a nonsensical device configuration. Device support for UDP segmentation offload requires checksum offload in hardware as well. Syzbot has discovered the first case, 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, skip bad offload detection when gso_segment has returned nothing. We know that in such case the egress device supports the desired GSO offload, which implies that it can fill in L4 checksums. Hence we don't need to check the skb->ip_summed value, which reflects the egress device checksum capabilities. 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/core/gso.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/core/gso.c b/net/core/gso.c index bcd156372f4d..88d5ca7d4fe7 100644 --- a/net/core/gso.c +++ b/net/core/gso.c @@ -122,10 +122,12 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb, skb_reset_mac_len(skb); segs = skb_mac_gso_segment(skb, features); + if (IS_ERR_OR_NULL(segs)) + goto out; - if (segs != skb && unlikely(skb_needs_check(skb, tx_path) && !IS_ERR(segs))) + if (segs != skb && unlikely(skb_needs_check(skb, tx_path))) skb_warn_bad_offload(skb); - +out: return segs; } EXPORT_SYMBOL(__skb_gso_segment); From patchwork Thu Aug 1 13:52:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Sitnicki X-Patchwork-Id: 13750555 X-Patchwork-Delegate: kuba@kernel.org Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (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 139241A38C1 for ; Thu, 1 Aug 2024 13:53:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722520410; cv=none; b=QdedMhMlvn6BJmL6a/gGHRbAcvx2WnAFrAsWeOUtsbrgeCNApuWejpd6EsJ7fwQkROMD5/WavkKfhJ5Fk+paZAoYwRwvtB+/bvxcQa9+BzCzqPiPOa1V46CvQKFSi0Iq/FIT/s6L8G7D3WZQqowzCDlZmtpaxMYLP52U/8X7zdk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722520410; c=relaxed/simple; bh=gWWdO5xBWX5tU7fXTnRIHBQdQkp9TESMBHiNigorEHA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=rfuUSBMV81hfJr2qxrsP2i+VR+L/MuZPTUfVOkOfKZ8ALcpu9KHUhpxxnN3ZapEU5Sm2NzAvbSWJTaD83yX2QXf8L91BD5lHjWDMkTke2gIKfhOkCCU1X8cifg0JkZfROhfamchQighcfdAlN/SPRN9rB5iXK8QJ3o7KwJdN0jA= 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=HAa5+eCv; arc=none smtp.client-ip=209.85.208.41 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="HAa5+eCv" Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5a10835480bso10183039a12.2 for ; Thu, 01 Aug 2024 06:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1722520407; x=1723125207; 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=HAa5+eCvOLgUVnJvfbhwqz8Z1l5tLrPhMh7H/BDp1RItVc1KvcNlX6/Fw6VZ9oDyaB TLLoPiTRbC4otJSbrZa15mR/hDfp2e6QjH49GMuAETR1a/Qu280iFTJrVPph0+VDRHet +RnINa+cFILPWM6uR6eG5ixevATCuOtUceQ4fe5w688f46arm94mDNVNNup4TNZZ1oXI bEVtmuwhhjWDc4cwW9wlybUrpnHMGgF+1RtvCxKDLuN7J+azQJm5c9UeoXJwRY2nonaX oLbUC4LRDkLhzlClGVuFRPcmPlGiBpT4E6q0vefB1CxLC9vRWH9+DR8MM4JhNuHXOL/C 91TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722520407; x=1723125207; 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=M0aNgJXyGVzdG1JSOZb85qp2ney01bRCWL5Ky4nnn0PYIk/B94OHE2afQuyCMcjaWS OQOcQZP1NT/ilgRufMQlWdaRjBePfNY79+cWEU3VlrJotWC2UiI2MNFt6rVBVKHjSSKA RLkNvgLFTH7YSVs4FKW4He+2A7NLoOOk5QyUcgMcYZGjgN0bei5dkrvq5NZSzjjitsjD c87q35Pm9OFydnNEJ0ANtbl/ewaKQoR20uHs8zxKLN+fUS24RMljkVOhJ7emS+dc6+qr prDNsRHTnpfodVpctKdbnM28YUbLrvbTvHC8al7+ykiqxODNflR7waL1XnH19HuT/VsO WDrA== X-Gm-Message-State: AOJu0YwvyrUwP26OReHTzf1UwrlBVMWqPPR3P+LEgfDzr2HTDgtdjv7K 8MyGAn58Og2uPtLVm4fySNdNhSomW37N+sk/ClVmNy7OZSF0RQeOTYU2AEWT+rQ= X-Google-Smtp-Source: AGHT+IH+yacwyAUQPqgzg0lVvZIIxA7JqngOa1jL/lnwNp2hFFya9gzj9Z8wbfNvyhXdzxbnLX6PJw== X-Received: by 2002:aa7:d357:0:b0:5a3:2af5:c722 with SMTP id 4fb4d7f45d1cf-5b7f38ebb2dmr279070a12.13.1722520400691; Thu, 01 Aug 2024 06:53:20 -0700 (PDT) Received: from cloudflare.com ([2a09:bac5:5063:2387::38a:2f]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5ac63593a8esm10198000a12.30.2024.08.01.06.53.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Aug 2024 06:53:20 -0700 (PDT) From: Jakub Sitnicki Date: Thu, 01 Aug 2024 15:52:54 +0200 Subject: [PATCH net v2 2/2] 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: <20240801-udp-gso-egress-from-tunnel-v2-2-9a2af2f15d8d@cloudflare.com> References: <20240801-udp-gso-egress-from-tunnel-v2-0-9a2af2f15d8d@cloudflare.com> In-Reply-To: <20240801-udp-gso-egress-from-tunnel-v2-0-9a2af2f15d8d@cloudflare.com> To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Willem de Bruijn , kernel-team@cloudflare.com 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 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;