Re: [PATCH net v2] net: fec: reject oversized fragments before bounce-buffer memcpy

NXP Confidential

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Thursday, September 24, 2026 7:41 AM
To: Aldo Ariel <redacted>
Cc: Wei Fang <wei.fang@nxp.com>; Frank Li <frank.li@nxp.com>; Shenwei Wang
[off-list ref]; imx@lists.linux.dev; netdev@vger.kernel.org; linux-
kernel@vger.kernel.org; stable@vger.kernel.org; Sashiko <sashiko-
bot@kernel.org>
Subject: [EXT] Re: [PATCH net v2] net: fec: reject oversized fragments before
bounce-buffer memcpy

Caution: This is an external email. Please take care when clicking links or opening
attachments. When in doubt, report the message using the 'Report this email'
button


On Wed, Sep 23, 2026 at 06:22:01PM -0300, Aldo Ariel wrote:

quoted

Hi Andrew,

PKT_MAXBUF_SIZE = round_down(2048 - 64, 64) = 1984 max_mtu (non-jumbo)
= 1984 - VLAN_ETH_HLEN - ETH_FCS_LEN = 1962

So for standard MTU, max_mtu < FEC_ENET_TX_FRSIZE and individual
fragments should not exceed the bounce buffer.

However, when the device supports jumbo frames, max_buf_size =
MAX_JUMBO_BUF_SIZE (~16256) and max_mtu reaches ~16234.
Scatter-gather fragments in that case can exceed FEC_ENET_TX_FRSIZE
while still needing the bounce path for alignment or byte-swap.

Should I respin with a check only for the jumbo path, or is the
unconditional guard acceptable?

Can bounce buffers and jumbo be used at the same time?

No. Bounce buffer is only available on i.mx28.

Shenwei

How is the scatter-gather size determined? Maybe the better fix is to set the
fragment size based on the size of the bounce buffer when it is in use?

        Andrew