netdev - RE: [PATCH v2 net-next 3/5] et: fec: add rx_frame_size to support configurable RX length

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:
 <AM9PR04MB850566622D29C9EBB70B69188839A@AM9PR04MB8505.eurprd04.prod.outlook.com>
Date: Tue, 26 Aug 2025 01:43:56 +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.
> 
> I don't think there is a case that rx_frame_size is 3520 while the max_buf_size is
> 1984.
> With the patch, the rx_frame_size should always less than the max_buf_size.
> Otherwise,
> the implementation might have a logic bug.
> 

Actually, I have tested this patch set, that is the problem I'm seeing. You can also
have a try, do not enable jumbo frame, just use the default configuration.