Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp4647561rwb; Tue, 20 Sep 2022 17:51:33 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5P0Lt8pTiqIIPG4UahMFxV45ht1iK+0EKi4grboYuwD0qVO1jmWJDqNlw1Z0c+hS4WvjJ2 X-Received: by 2002:a05:6402:5489:b0:43b:b935:db37 with SMTP id fg9-20020a056402548900b0043bb935db37mr23373647edb.347.1663721492852; Tue, 20 Sep 2022 17:51:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663721492; cv=none; d=google.com; s=arc-20160816; b=zrF93SqcpyUSs2Z4j7ixeFas/f9iCGLC+lqhdFI1ftKItNHL7Gb8fZInAhekLPV7Yv DDDEzAHluDFcjhxhPPJ4kjWo2r7PhmmJ3ji6cPAdMjfDfVmQhPnXtz9yadGXbEKnKkB+ KY4wIdJOua6/LR37gLdHP7ZiC1WXA2HMudJK485cK4qH1zZD5hq1gjVE1pVoCXINqZo8 +jK233rXDxSmiO+gAH9bMN+pReqTiIKGlzxzY+xxsbuhkMQMdsosREhkEo69nD2xWifc ReYW1FpY4HdgREkewku1ISGSuKyyijwpyyYP+SRtqYm9ptcFNMS3WWsVwRYQRqU509eb MKEA== 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=WvtuIC2+7UN+fsO1GntQ4dE7hCbVNiKYWo69DvPZRd0=; b=zX5YojEIcTmqJ4JvPJOFCkcfGsYLTRXtC8vPUPjKCxV0bbq7NZHjzCeL1ja5LzwTSc Z+hOA2lfEsQeJ+Ivu1z6KXI8Z4NNiu/FfTDdjCRq84EQlz2srKFmIQaQzi1ccfqtS9Mt xuAqY4tLkts24B9Ntc6aIyzYKyHukZX4/q7cf+HKgErDjQNvxDbi0HxwJJvB9dn2ysY+ KhpIPhvBR5i1GAOOz3yQrzRKs0tdkCYk5AdFeMGSLoHCLoYbHFC+Irvc6O3aUE3kVDbh fVonXb+8TNz6e5KpVYKuFvqLmvFzWepEZcyyXk0dUQOXDK7A6rhWb/YNaFx2MA7MCNyD G8Ew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Dx42PJJU; 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 h8-20020a05640250c800b00451e0d930dfsi1323134edb.497.2022.09.20.17.51.07; Tue, 20 Sep 2022 17:51:32 -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=Dx42PJJU; 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 S230346AbiITXu3 (ORCPT + 99 others); Tue, 20 Sep 2022 19:50:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229751AbiITXuZ (ORCPT ); Tue, 20 Sep 2022 19:50:25 -0400 Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A04F22E9DC; Tue, 20 Sep 2022 16:50:23 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id c6so3277883qvn.6; Tue, 20 Sep 2022 16:50:23 -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=WvtuIC2+7UN+fsO1GntQ4dE7hCbVNiKYWo69DvPZRd0=; b=Dx42PJJUwrlyYFbJdex7467PazS9KGMhPITrZNJzBcVmyZHKWnMXiiwvjrXJHY1Kj+ J+zL5FfP8BNnwrPN5XHeQrMbGrVAaLCmQlaeMfbQnX+ybXPbJ3OaT1e/5rUMc+VwH959 5jOmSPtok1i6ftZ3OJUKqakrNirwWjHep6g/iR23+mTGEdZGR7elJ6Y0peHsgUjij5Ko c0+Mfvi5zOc3VTQa0Nqdbkx2L9y4/MCBNJ2xeR7E+1L8UOlPw6wZJtUVtf+ND1P2Zc5I +Uq1gXA1awz4RMHMASeNEPJCnyNIQKA2bYhucxuU++EBe8DQfPWgKv4hoZTWQygVtAn5 /ulA== 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=WvtuIC2+7UN+fsO1GntQ4dE7hCbVNiKYWo69DvPZRd0=; b=BWPMzw1yHnjjrh5DXjFh9/wa5TFPIRGqkAFabPIJWrKMZS+r1y1wpSDD4NVhVThEFU r09TTaHvjao0MXiDJbNi9ViZ4fxT+iUUQs4glYlBAWo9pm/i47NNWif16dWK5Ntiu1xx 4QE7cOZpOBDa25NAMsZdzc4NY1CgcrgkKPN2a1ZEt1p7pD5r89LxKuDXknp2AqkD3UmN MSyOGVCMJqGpfKDvyOdgHJ0oSOvU0bMxA3D3Ol50B5VvfX/AmzhQdERCp5L5D9jfdZXB 1ctb17+bKvTmmQOrOqRiJ90FnHXaRe9ATfK042YnxHF5tqxcwBx19ZIdB/T91tdTk0j9 Xe9A== X-Gm-Message-State: ACrzQf02BAmMUNZyK2Qk+aNOBMamo55wpKw+knB5K9BNckZ1WuWqvNhn ySsPWjXZ9J90wJpwmpmfyGs= X-Received: by 2002:a05:6214:2303:b0:4ad:58f2:7ca4 with SMTP id gc3-20020a056214230300b004ad58f27ca4mr5207138qvb.89.1663717822500; Tue, 20 Sep 2022 16:50:22 -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 o13-20020a05620a2a0d00b006baef6daa45sm806039qkp.119.2022.09.20.16.50.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Sep 2022 16:50:21 -0700 (PDT) From: Sean Anderson To: "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org (open list), Nick Bowler , Rolf Eike Beer , Zheyu Ma , Sean Anderson , Andrew Lunn Subject: [PATCH net v2] net: sunhme: Fix packet reception for len < RX_COPY_THRESHOLD Date: Tue, 20 Sep 2022 19:50:18 -0400 Message-Id: <20220920235018.1675956-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. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Sean Anderson Reviewed-by: Andrew Lunn --- Changes in v2: - Add Fixes tag 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 1921054b7f7d..e660902cfdf7 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