Netdev List
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
Cc: maxime.chevallier@bootlin.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] net: stmmac: guard FCS stripping against runt frames
Date: Wed, 23 Sep 2026 22:53:50 +0200	[thread overview]
Message-ID: <54796d52-7656-43f6-9ca9-7bdd10db0a76@lunn.ch> (raw)
In-Reply-To: <20260923193354.1537557-1-qwe.aldo@gmail.com>

On Wed, Sep 23, 2026 at 04:33:54PM -0300, Aldo Ariel Panzardo wrote:
> Hi Andrew,
> 
> You're right that the relevant question is not merely whether the MAC can
> forward frames shorter than 64 bytes, but whether a descriptor with a
> reported length smaller than ETH_FCS_LEN can reach this path.
> 
> I found a closer NXP/Freescale reference: the i.MX RT1170 ENET_QOS
> documentation (IMXRT1170RM, Chapter 61), which describes the Synopsys
> DWC EQoS receive descriptors used by this driver:
> 
>   https://www.nxp.com/webapp/Download?colCode=IMXRT1170RM
> 
> The MTL receive configuration explicitly supports forwarding error packets
> and undersized good packets (FEP/FUP), and RDES3.PL is documented as
> the number of bytes transferred to system memory, including CRC. I don't
> see a documented lower bound on PL.

Will, a frame which is smaller than the FCS cannot pass the FCS
check. So you don't need to worry about undersized good packets
hitting this condition.

Given that an ethernet header is 14 octets the FCS is 4 octets, any
frame smaller than 18 octets should be dropped by the network
stack. So why not do one test at the beginning for ETH_HLEN +
ETH_FCS_LEN?

	Andrew


  reply	other threads:[~2026-09-23 20:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23 16:23 [PATCH] net: stmmac: guard FCS stripping against runt frames Aldo Ariel Panzardo
2026-09-23 19:03 ` Andrew Lunn
2026-09-23 19:33   ` Aldo Ariel Panzardo
2026-09-23 20:53     ` Andrew Lunn [this message]
2026-09-23 20:37 ` Lorenzo Bianconi
2026-09-24  2:16   ` Andrew Lunn
2026-09-24  7:57     ` Lorenzo Bianconi
2026-09-24 12:51       ` Andrew Lunn
2026-09-24 13:10         ` Lorenzo Bianconi
     [not found]           ` <CAP48HfvkCNb2_UnpvTvn_O3K+vgtDK55JjXPBF0cbBrmb_6oCA@mail.gmail.com>
2026-09-24 14:10             ` Andrew Lunn
2026-09-27 16:38 ` netdev-bot+sashiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54796d52-7656-43f6-9ca9-7bdd10db0a76@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=qwe.aldo@gmail.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox