From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D08B1C4320A for ; Fri, 20 Aug 2021 16:26:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B435A610CA for ; Fri, 20 Aug 2021 16:26:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231887AbhHTQ1D (ORCPT ); Fri, 20 Aug 2021 12:27:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:50286 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229564AbhHTQ1B (ORCPT ); Fri, 20 Aug 2021 12:27:01 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0A6F861057; Fri, 20 Aug 2021 16:26:24 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mH7LZ-006EXS-SX; Fri, 20 Aug 2021 17:26:22 +0100 Date: Fri, 20 Aug 2021 17:26:21 +0100 Message-ID: <87fsv4qdzm.wl-maz@kernel.org> From: Marc Zyngier To: Matteo Croce Cc: Eric Dumazet , Thierry Reding , netdev@vger.kernel.org, Linux Kernel Mailing List , linux-riscv , Giuseppe Cavallaro , Alexandre Torgue , "David S. Miller" , Jakub Kicinski , Palmer Dabbelt , Paul Walmsley , Drew Fustini , Emil Renner Berthing , Jon Hunter , Will Deacon Subject: Re: [PATCH net-next] stmmac: align RX buffers In-Reply-To: References: <20210614022504.24458-1-mcroce@linux.microsoft.com> <871r71azjw.wl-maz@kernel.org> <202417ef-f8ae-895d-4d07-1f9f3d89b4a4@gmail.com> <87o8a49idp.wl-maz@kernel.org> <20210812121835.405d2e37@linux.microsoft.com> <874kbuapod.wl-maz@kernel.org> <87wnohqty1.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: mcroce@linux.microsoft.com, eric.dumazet@gmail.com, thierry.reding@gmail.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, peppe.cavallaro@st.com, alexandre.torgue@foss.st.com, davem@davemloft.net, kuba@kernel.org, palmer@dabbelt.com, paul.walmsley@sifive.com, drew@beagleboard.org, kernel@esmil.dk, jonathanh@nvidia.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Aug 2021 11:37:03 +0100, Matteo Croce wrote: > > On Thu, Aug 19, 2021 at 6:29 PM Marc Zyngier wrote: [...] > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h > > index fcdb1d20389b..244aa6579ef4 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h > > @@ -341,7 +341,7 @@ static inline unsigned int stmmac_rx_offset(struct stmmac_priv *priv) > > if (stmmac_xdp_is_enabled(priv)) > > return XDP_PACKET_HEADROOM + NET_IP_ALIGN; > > > > - return NET_SKB_PAD + NET_IP_ALIGN; > > + return 8 + NET_IP_ALIGN; > > } > > > > void stmmac_disable_rx_queue(struct stmmac_priv *priv, u32 queue); > > > > I don't see the system corrupting packets anymore. Is that exactly > > what you had in mind? This really seems to point to a basic buffer > > overflow. [...] > Sorry, I meant something like: > > - return NET_SKB_PAD + NET_IP_ALIGN; > + return 8; > > I had some hardware which DMA fails if the receive buffer was not word > aligned, but this seems not the case, as 8 + NET_IP_ALIGN = 10, and > it's not aligned too. No error in that case either, as expected. Given that NET_SKB_PAD is likely to expand to 64, it is likely a DMA buffer overflow which probably only triggers for large-ish packets. Now, we're almost at -rc7, and we don't have a solution in sight. Can we please revert this until we have an understanding of what is happening? I'll hopefully have more cycles to work on the issue once 5.14 is out, and hopefully the maintainers of this driver can chime in (they have been pretty quiet so far). Thanks, M. -- Without deviation from the norm, progress is not possible.