Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1814503rwb; Sun, 18 Sep 2022 15:14:35 -0700 (PDT) X-Google-Smtp-Source: AMsMyM55bziDWKXIZniYRyNLPZooW04atHBchLOghY5khbyIdN4fKRGhOFkGnQh62Z+ZMG8twBSh X-Received: by 2002:a65:6bd3:0:b0:42b:9117:b9d1 with SMTP id e19-20020a656bd3000000b0042b9117b9d1mr13279424pgw.238.1663539275758; Sun, 18 Sep 2022 15:14:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663539275; cv=none; d=google.com; s=arc-20160816; b=DYfW7oqn21Ouo0KX8w82pxhPVhWNUadFlTIGRswNPZUJJtZ85tjVvN38C53aGrp1rl +zY1qRMlaIegpc61GA9KLh6phXXSkhG1t6CkV+++3JlVkhTSXNgGZWugRub7elEU/03o JyHY1EB3QUrtz4tmK3g/yD8PFWj/ekyRcehRgIhJbEiyaETTAGDrfUcq7b+fw6jDSCnZ lIaxyG62UZVwzfvkvL+1KFbe2HC+89650Kcv/cZycNf6/qV0FkarEmze4xUV+FMHOxLj qU00bier8aNnOspmIY1IptIv4K8OtvU3B9gVhlGTHZ4BkyhCdvuFzw5n3hmXI+EC2Z01 8b5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=z0B/eW5XdmdQCHytKnRy9T9V8L1fTqHGR2VXSGfuq4I=; b=oKUDO8oIuINN+DP26sJnEcvtw28YPafYMKzBrVJXRTuY4IPyCZIb2BApetWnu4Wy4F JaOmlWEwDl3te2Dofw6EY8yyP8HMxn9btaVj8ZDLLDA4b+fbnQq4xW8ODmituBEgwO/x O4iukWbmHXXhZG9jzO1G7OjKd3iPRgI3tB2BFe9bcXlM10oOyRWTjcnL05c5ceig53c4 5BC8eC/VXAyb/gRiTVQaZ/lsHBt6u5b+jgVYj5D4jYNFlcKpWHWYTXgUqDIpmzvZYQok oiFtKxt/DkRD7hgEYMwOP6Qs+e2qC+Yp4cRd+uecbfj1c+dhpoxNsVVdEeM4pd0GpR72 EgFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ltK6KC15; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cm9-20020a056a00338900b0054a22e82eaesi9320326pfb.301.2022.09.18.15.14.23; Sun, 18 Sep 2022 15:14:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ltK6KC15; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229606AbiIRVzm (ORCPT + 99 others); Sun, 18 Sep 2022 17:55:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229518AbiIRVzj (ORCPT ); Sun, 18 Sep 2022 17:55:39 -0400 Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC84C13D67; Sun, 18 Sep 2022 14:55:38 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id c6so20662636qvn.6; Sun, 18 Sep 2022 14:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date; bh=z0B/eW5XdmdQCHytKnRy9T9V8L1fTqHGR2VXSGfuq4I=; b=ltK6KC15zGQUC9Lw70LjnFqZjNPrfIX+TMuW8tMBmsHN7UPzHasBO5dW87D7S893S3 LlsUUANfPgJVqKjn4vzrR2JILxzqawVFobYr7CB9LWDiT+2Dg7Hv9e8PctQ5/ZsXQwmt Li53kzoT/jeRa5eO9FrILsRSHLT7l/zNiQa7AFKG+lRsJXoJY+MsTLSpGKF3fhy7RKdA vh8fYiKPWq9zddTHUfx8Dh9K/I9H0yJMC1vxxED3U0/ub8D+DF5LsJSYaD4T3kzplrJV Bb542dZOZj8a/1THY+orbiASDoVbDbhDrJWoXcugsoiOtsTCIgYMJtq9azU3dUGfY2S+ yxOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date; bh=z0B/eW5XdmdQCHytKnRy9T9V8L1fTqHGR2VXSGfuq4I=; b=qbf1RsHjmFxnrQB/HVpTLW52G+9Xzb66G3FS4rfI+b4HgAYZeuRwtKFxq9Lxqis2XJ aeh16+j6ua7MqEg8P9gM9saidtMkra7EZMrK0Pk2W4FoBQQYkQEWuds6C7chu1nin1QV WygZXcqujDrGMMRH9VC0gNI4QnPYQlQzkwMhfKjc2hmvMQNv14LTPcwD0l262UAgccH8 p1bdDVbNoSgpL9Nzagj2HduF75nM28ThkBwr1274Xlpg+Re4oB1ggoarOY6z7DTE+fqn IWD7j/jZefvEOwtEItb4E3caknPsptozfKf9FA1oKkwsOz8uP1xAdGuVQJW33CTXLAkZ Kdwg== X-Gm-Message-State: ACrzQf1W+kgl0xaOxcyeIZI6e7tjIIczcniPHPyEJBwcvZmD6ER7Wdra ruZkuvNKJwiQZuAs0/aToAN8uwm4FmUJOw== X-Received: by 2002:a05:6214:519e:b0:4ad:25c4:cb21 with SMTP id kl30-20020a056214519e00b004ad25c4cb21mr6175544qvb.41.1663538137919; Sun, 18 Sep 2022 14:55:37 -0700 (PDT) Received: from localhost (pool-173-73-95-180.washdc.fios.verizon.net. [173.73.95.180]) by smtp.gmail.com with UTF8SMTPSA id j15-20020a05620a410f00b006b5df4d2c81sm12100134qko.94.2022.09.18.14.55.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Sep 2022 14:55:37 -0700 (PDT) From: Sean Anderson To: "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org Cc: Zheyu Ma , linux-kernel@vger.kernel.org (open list), Rolf Eike Beer , Nick Bowler , Sean Anderson Subject: [PATCH] net: sunhme: Fix packet reception for len < RX_COPY_THRESHOLD Date: Sun, 18 Sep 2022 17:55:34 -0400 Message-Id: <20220918215534.1529108-1-seanga2@gmail.com> X-Mailer: git-send-email 2.37.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org There is a separate receive path for small packets (under 256 bytes). Instead of allocating a new dma-capable skb to be used for the next packet, this path allocates a skb and copies the data into it (reusing the existing sbk for the next packet). There are two bytes of junk data at the beginning of every packet. I believe these are inserted in order to allow aligned DMA and IP headers. We skip over them using skb_reserve. Before copying over the data, we must use a barrier to ensure we see the whole packet. The current code only synchronizes len bytes, starting from the beginning of the packet, including the junk bytes. However, this leaves off the final two bytes in the packet. Synchronize the whole packet. To reproduce this problem, ping a HME with a payload size between 17 and 214 $ ping -s 17 which will complain rather loudly about the data mismatch. Small packets (below 60 bytes on the wire) do not have this issue. I suspect this is related to the padding added to increase the minimum packet size. Signed-off-by: Sean Anderson Patch-prefix: net --- drivers/net/ethernet/sun/sunhme.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/sun/sunhme.c b/drivers/net/ethernet/sun/sunhme.c index 8594ee839628..88aa0d310aee 100644 --- a/drivers/net/ethernet/sun/sunhme.c +++ b/drivers/net/ethernet/sun/sunhme.c @@ -2020,9 +2020,9 @@ static void happy_meal_rx(struct happy_meal *hp, struct net_device *dev) skb_reserve(copy_skb, 2); skb_put(copy_skb, len); - dma_sync_single_for_cpu(hp->dma_dev, dma_addr, len, DMA_FROM_DEVICE); + dma_sync_single_for_cpu(hp->dma_dev, dma_addr, len + 2, DMA_FROM_DEVICE); skb_copy_from_linear_data(skb, copy_skb->data, len); - dma_sync_single_for_device(hp->dma_dev, dma_addr, len, DMA_FROM_DEVICE); + dma_sync_single_for_device(hp->dma_dev, dma_addr, len + 2, DMA_FROM_DEVICE); /* Reuse original ring buffer. */ hme_write_rxd(hp, this, (RXFLAG_OWN|((RX_BUF_ALLOC_SIZE-RX_OFFSET)<<16)), -- 2.37.1