Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1087604imm; Tue, 2 Oct 2018 02:27:48 -0700 (PDT) X-Google-Smtp-Source: ACcGV63CC+liCNIYXdeZZOo16oORvoRb+1Wyui/2Oy+eV28mL7RmHE8hu5Mghlsh7fouNmQoj7b/ X-Received: by 2002:a63:5b63:: with SMTP id l35-v6mr13727914pgm.50.1538472468058; Tue, 02 Oct 2018 02:27:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538472468; cv=none; d=google.com; s=arc-20160816; b=vMGs0dzOnq/xnk6lI82/poEDRx2AKytPaT6HRiGGdTZUCgsZLSq8oJ7P2r4h5z7E81 PZCroNoBSNp6Cln6svaEBrQR4dtrFv4N3hQwJIB429bxB3dQI9mQI8sI7c0yxCOC5jJT ad6rcPlAL1aEN/DQBs+246EE/nhw+9CMImyb1bYV0Z9YkyAuoj0Sj31+2n2mwYRM1YLK LtOEhkxMj7YU54AM64BPfgrYb8Qft0soRhl19dogwWbVrKpkdfi2LK1ICQ/SAK1oja3F vUKVb5tcHW0BUdgKk04yISOCe2BdvBC3XOykWOgnsKX6qALLNICV5ZExM7v69iBLGU5s ik1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=kaMWabtu27smC6emSlR3gK0NMj0+9v+M2MS5dIzNz5c=; b=ziV3gfb4+FJCSK2d3TPLEcpckCDyZufy3JMicYA1h1e4x/dLJAzogWN3NkbJexHRgb +26Mzr9DokDJT6pWJh8BSvhzkIfMApO4WcVX3BK/kyOof8+Y1z6vhGgHlXNG8UvHOS17 2bBjxE4tv/TWgXs58Yv8cIHEs2h3kKt2oE5X+iEu6FFOAM8PqzXTMBcO1XWboUcekpIn 26DNZ/GzXy4jRPtRafMflItwIFX8ExddlEV4BycbrEbThbzzw8EL5+pQ3d1LK0uM/rUq JsxX4tNhhhgqZh+yGO5ZqiHNr/SyimFNPQL448oYx+A/5yjnTP8ZRrOtOAwv/p8Wuays 1Mpg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t127-v6si16647280pfc.118.2018.10.02.02.27.33; Tue, 02 Oct 2018 02:27:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727535AbeJBQJb (ORCPT + 99 others); Tue, 2 Oct 2018 12:09:31 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:50409 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727160AbeJBQJM (ORCPT ); Tue, 2 Oct 2018 12:09:12 -0400 Received: from [148.252.241.226] (helo=rainbowdash) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1g7Gx6-0002zb-Di; Tue, 02 Oct 2018 10:26:48 +0100 Received: from ben by rainbowdash with local (Exim 4.91) (envelope-from ) id 1g7Gx6-0000Jh-5c; Tue, 02 Oct 2018 10:26:48 +0100 From: Ben Dooks To: netdev@vger.kernel.org Cc: oneukum@suse.com, davem@davemloft.net, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kernel@lists.codethink.co.uk, Ben Dooks Subject: [PATCH 3/4] usbnet: smsc95xx: check for csum being in last four bytes Date: Tue, 2 Oct 2018 10:26:44 +0100 Message-Id: <20181002092645.1115-4-ben.dooks@codethink.co.uk> X-Mailer: git-send-email 2.19.0 In-Reply-To: <20181002092645.1115-1-ben.dooks@codethink.co.uk> References: <20181002092645.1115-1-ben.dooks@codethink.co.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The manual states that the checksum cannot lie in the last DWORD of the transmission, so add a basic check for this and fall back to software checksumming the packet. This only seems to trigger for ACK packets with no options or data to return to the other end, and the use of the tx-alignment option makes it more likely to happen. Signed-off-by: Ben Dooks --- drivers/net/usb/smsc95xx.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c index d244357bf1ad..46385a4b8b98 100644 --- a/drivers/net/usb/smsc95xx.c +++ b/drivers/net/usb/smsc95xx.c @@ -2003,6 +2003,20 @@ static u32 smsc95xx_calc_csum_preamble(struct sk_buff *skb) return (high_16 << 16) | low_16; } +/* The CSUM won't work if the checksum lies in the last 4 bytes of the + * transmission. This is fairly unlikely, only seems to trigger with some + * short TCP ACK packets sent. + * + * Note, this calculation should probably check for the alignment of the + * data as well, but a straight chec for csum being in the last four bytes + * of the packet should be ok for now. +*/ +static bool smsc95xx_can_checksum(struct sk_buff *skb) +{ + unsigned int len = skb->len - skb_checksum_start_offset(skb); + return skb->csum_offset < (len - (4 + 1)); +} + static struct sk_buff *smsc95xx_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags) { @@ -2031,7 +2045,8 @@ static struct sk_buff *smsc95xx_tx_fixup(struct usbnet *dev, } if (csum) { - if (skb->len <= 45) { + /* note, csum does not work if csum in last DWORD of packet */ + if (skb->len <= 45 || !smsc95xx_can_checksum(skb)) { /* workaround - hardware tx checksum does not work * properly with extremely small packets */ long csstart = skb_checksum_start_offset(skb); -- 2.19.0