Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1619691pxb; Fri, 20 Aug 2021 09:43:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+HJ52TOh06pHPchOwMXU117pAO++S4WGM/Bng1jpUAkJBxIwwPtEVmxSx/NfAKgxJRcFF X-Received: by 2002:a50:e0c3:: with SMTP id j3mr24084267edl.307.1629477793565; Fri, 20 Aug 2021 09:43:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629477793; cv=none; d=google.com; s=arc-20160816; b=kIc2oXtG34oNcH1WuhjC8UfCJ4PtHF9LQMEJFomod6KXbDu2rbXHSYv12Zvc8/9aKz m1HWA9zQIj2gD9/mEee5AhpzRBePIkZnm4RJpYdjZ2KyCWs+hGC34s6Hd+ZIAhYpjApD 6W7l8jhTYWfko1R8HKNeI9w2kbhtc/WY5isDNx7zQT4yMPRVguDRCwxYEtcC2INVAZS4 L/Oys5S4fCym0/ZLkoMijR1UYc4O8prMcpcNHySREIITmgyo23a4UuKZIkcxqJNZXvYy g871Aw6rauxrxA2jP+r/5h3h2D3AYND1i2xbKp395SVnL/5Ko6hqOeKXjh0tXriz2Bxw fLdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature:dkim-filter; bh=WaK5G/evZ18+jqtp1X6uZFuicVOVUnSl34NTPmE/jIc=; b=v2AXEStRpa9uMeJ34nM8+Kc+4YjnIKaEzMqGBDwBQ1GD148AuukthLKyFof9xgjFvA FB9wG6FMT+aeExihSjf51VVfZ+mzfzLM6f3TNj2mKOmXFH/DbxeLOFIk7EkntggfGssZ 3bhONKISNBC5UNtkimryHk+bSOKT2tggpHFs5rLjlvUXmzO5Dz344P5138bZSprhsP5D huJMmg0ZBwFddfmFR5lqlK5yUY+9dGGxvP7uvX8vCMBH/Vsnxhhv6h7G60D6ZtuioggP wisg+yVV3qJq03u8O3gAqY5Ukzl2Vy4kau589P5Z2F1drJHT1W04PGYN8j1WcJk6N/vs +rYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=eYmin74t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d13si6608960eds.452.2021.08.20.09.42.45; Fri, 20 Aug 2021 09:43:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=eYmin74t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231890AbhHTQja (ORCPT + 99 others); Fri, 20 Aug 2021 12:39:30 -0400 Received: from linux.microsoft.com ([13.77.154.182]:60678 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231757AbhHTQj3 (ORCPT ); Fri, 20 Aug 2021 12:39:29 -0400 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by linux.microsoft.com (Postfix) with ESMTPSA id 3696D20C33D8; Fri, 20 Aug 2021 09:38:51 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 3696D20C33D8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1629477531; bh=WaK5G/evZ18+jqtp1X6uZFuicVOVUnSl34NTPmE/jIc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=eYmin74tZXjXnVDwQL3iH5Eaw5f/w7gQT7W/KU38DOtTsgd2G5d1u5Wthggk5RarQ z/iWL/PT4rXm+b4YsDV6UYHIDqYl5ahnIDmZHXGMDuQt5aK6SpqZKhiz5zudBiVGMS uO13TbWtoDrh2RSHx77oe+pIl8wmdMbpKXK7GBn4= Received: by mail-pf1-f178.google.com with SMTP id t13so9074512pfl.6; Fri, 20 Aug 2021 09:38:51 -0700 (PDT) X-Gm-Message-State: AOAM533NQKoy0UBjsmzK3zTzXMk6Xb+1bLY7f3pSC1Sg7I2C3NG1MU1z 5PnzUD8CEqrT+4GkYew8cJfTXo7k3JH+G3LC1jk= X-Received: by 2002:a63:1422:: with SMTP id u34mr1216269pgl.326.1629477530715; Fri, 20 Aug 2021 09:38:50 -0700 (PDT) MIME-Version: 1.0 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> <87fsv4qdzm.wl-maz@kernel.org> In-Reply-To: <87fsv4qdzm.wl-maz@kernel.org> From: Matteo Croce Date: Fri, 20 Aug 2021 18:38:14 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH net-next] stmmac: align RX buffers To: Marc Zyngier 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 20, 2021 at 6:26 PM Marc Zyngier wrote: > > 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. Last try, what about adding only NET_IP_ALIGN and leaving NET_SKB_PAD? - return NET_SKB_PAD + NET_IP_ALIGN; + return NET_IP_ALIGN; I think that alloc_skb adds another NET_SKB_PAD anyway. -- per aspera ad upstream