netdev - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20260125214446.3383999-1-kuba@kernel.org>
Date: Sun, 25 Jan 2026 13:44:46 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: wei.fang@....com
Cc: Jakub Kicinski <kuba@...nel.org>,
	john.fastabend@...il.com,
	linux-kernel@...r.kernel.org,
	shenwei.wang@....com,
	daniel@...earbox.net,
	frank.li@....com,
	netdev@...r.kernel.org,
	xiaoning.wang@....com,
	ast@...nel.org,
	sdf@...ichev.me,
	imx@...ts.linux.dev,
	davem@...emloft.net,
	edumazet@...gle.com,
	hawk@...nel.org,
	bpf@...r.kernel.org,
	pabeni@...hat.com,
	andrew+netdev@...n.ch
Subject: Re: [v4,net-next,06/15] net: fec: add fec_enet_rx_queue_xdp() for XDP path

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: fec: add fec_enet_rx_queue_xdp() for XDP path

This commit separates XDP path packet processing from protocol stack
packet processing by adding a new fec_enet_rx_queue_xdp() function.
The goal is to optimize XDP path logic and improve XDP performance.

> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index 0529dc91c981..86447a7cb963 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c

[ ... ]

> +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.
-- 
pw-bot: cr