linux-kernel - RE: [PATCH v2 net-next 3/5] et: fec: add rx_frame

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PAXPR04MB851035376B94859B359C3A05883EA@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Mon, 25 Aug 2025 02:26:01 +0000
From: Wei Fang <wei.fang@....com>
To: Shenwei Wang <shenwei.wang@....com>
CC: Clark Wang <xiaoning.wang@....com>, Stanislav Fomichev <sdf@...ichev.me>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, dl-linux-imx <linux-imx@....com>, Andrew Lunn
	<andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
	<daniel@...earbox.net>, Jesper Dangaard Brouer <hawk@...nel.org>, John
 Fastabend <john.fastabend@...il.com>
Subject: RE: [PATCH v2 net-next 3/5] et: fec: add rx_frame_size to support
 configurable RX length

> > > @@ -4563,6 +4563,7 @@ fec_probe(struct platform_device *pdev)
> > >  	pinctrl_pm_select_sleep_state(&pdev->dev);
> > >
> > >  	fep->pagepool_order = 0;
> > > +	fep->rx_frame_size = FEC_ENET_RX_FRSIZE;
> >
> > According to the RM, to allow one maximum size frame per buffer,
> > FEC_R_BUFF_SIZE must be set to FEC_R_CNTRL [MAX_FL] or larger.
> > FEC_ENET_RX_FRSIZE is greater than PKT_MAXBUF_SIZE, I'm not sure
> whether it
> > will cause some unknown issues.
> 
> MAX_FL defines the maximum allowable frame length, while TRUNC_FL
> specifies the threshold beyond
> which frames are truncated. Based on this logic, the documentation appears to
> be incorrect-TRUNC_FL
> should never exceed MAX_FL, as doing so would make the truncation
> mechanism ineffective.
> 
> This has been confirmed through testing data.
> 

One obvious issue I can see is that the Rx error statistic would be doubled
the actual number when the FEC receives jumbo frames.

For example, the sender sends 1000 jumbo frames (8000 bytes) to the FEC port,
without this patch set, the Rx error statistic of FEC should be 1000, however,
after applying this patch set (rx_frame_size is 3520, max_buf_size is 1984), I
can see the Rx error statistic is 2000.