linux-kernel - RE: [v4,net-next,06/15] net: fec: add fec_enet_rx_queue

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:
 <PAXPR04MB8510775746A1CAF835E365718893A@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Mon, 26 Jan 2026 02:09:13 +0000
From: Wei Fang <wei.fang@....com>
To: Jakub Kicinski <kuba@...nel.org>
CC: "john.fastabend@...il.com" <john.fastabend@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Shenwei Wang
	<shenwei.wang@....com>, "daniel@...earbox.net" <daniel@...earbox.net>, Frank
 Li <frank.li@....com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Clark Wang <xiaoning.wang@....com>, "ast@...nel.org" <ast@...nel.org>,
	"sdf@...ichev.me" <sdf@...ichev.me>, "imx@...ts.linux.dev"
	<imx@...ts.linux.dev>, "davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>, "hawk@...nel.org"
	<hawk@...nel.org>, "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "andrew+netdev@...n.ch"
	<andrew+netdev@...n.ch>
Subject: RE: [v4,net-next,06/15] net: fec: add fec_enet_rx_queue_xdp() for XDP
 path

> > +static int fec_enet_rx_queue_xdp(struct fec_enet_private *fep, int queue,
> > +				 int budget, struct bpf_prog *prog)
> > +{
> 
> [ ... ]
> 
> > +		switch (act) {
> > +		case XDP_PASS:
> > +			rxq->stats[RX_XDP_PASS]++;
> > +			/* The packet length includes FCS, but we don't want to
> > +			 * include that when passing upstream as it messes up
> > +			 * bridging applications.
> > +			 */
> > +			skb = fec_build_skb(fep, rxq, bdp, page, pkt_len);
> > +			if (!skb) {
> > +				fec_xdp_drop(rxq, &xdp, sync);
> > +				trace_xdp_exception(ndev, prog, XDP_PASS);
> > +			} else {
> > +				napi_gro_receive(&fep->napi, skb);
> > +			}
> > +			break;
> 
> On platforms with FEC_QUIRK_SWAP_FRAME (like i.MX28), the old code path
> would call swap_buffer() after XDP_PASS before building the skb. In the
> old fec_enet_rx_queue(), the flow was:
> 
>     fec_enet_run_xdp() returns FEC_ENET_XDP_PASS
>     -> if (ret != FEC_ENET_XDP_PASS) goto done; // continues
>     -> if (need_swap) swap_buffer(data, pkt_len);
>     -> fec_build_skb()
> 
> With this change, XDP_PASS goes directly to fec_build_skb() without
> calling swap_buffer(). Does this break XDP_PASS on i.MX28 where the DMA
> delivers data in wrong byte order? On such platforms, packets passed to
> the network stack would have incorrect byte order, causing protocol
> parsing failures.
> 
> The commit message says "XDP path does not support swap_buffer()" but the
> previous code did support it for XDP_PASS - the swap happened after the
> XDP program returned PASS but before the packet was handed to the stack.

Actually the previous code did not support swap_buffer() for XDP path,
see fec_enet_bpf():

static int fec_enet_bpf(struct net_device *dev, struct netdev_bpf *bpf)
{
	[...]
	switch (bpf->command) {
	case XDP_SETUP_PROG:
		/* No need to support the SoCs that require to
		 * do the frame swap because the performance wouldn't be
		 * better than the skb mode.
		 */
		if (fep->quirks & FEC_QUIRK_SWAP_FRAME)
			return -EOPNOTSUPP;
	[...]
	}
}

Therefore, xdp program will not be installed for those platforms which
need swap_buffer(). Because the XDP path and the traditional protocol
stack path were previously mixed in fec_enet_rx_queue(), the logic was
confused, which led to the AI making a misjudgment.

> --
> pw-bot: cr