linux-kernel - RE: [PATCH net] net: enetc: do not transmit redirected XDP frames when the link is down

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:
 <PAXPR04MB85103577C97139DE324AAC3788A3A@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Tue, 9 Dec 2025 09:08:08 +0000
From: Wei Fang <wei.fang@....com>
To: Vladimir Oltean <vladimir.oltean@....com>
CC: Claudiu Manoil <claudiu.manoil@....com>, Clark Wang
	<xiaoning.wang@....com>, "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "ast@...nel.org" <ast@...nel.org>,
	"daniel@...earbox.net" <daniel@...earbox.net>, "hawk@...nel.org"
	<hawk@...nel.org>, "john.fastabend@...il.com" <john.fastabend@...il.com>,
	"sdf@...ichev.me" <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>,
	"bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: RE: [PATCH net] net: enetc: do not transmit redirected XDP frames
 when the link is down

> On Fri, Dec 05, 2025 at 06:53:07PM +0800, Wei Fang wrote:
> > In the current implementation, the enetc_xdp_xmit() always transmits
> > redirected XDP frames even if the link is down, but the frames cannot
> > be transmitted from TX BD rings when the link is down, so the frames
> > are still kept in the TX BD rings. If the XDP program is uninstalled,
> > users will see the following warning logs.
> >
> > fsl_enetc 0000:00:00.0 eno0: timeout for tx ring #6 clear
> >
> > More worse, the TX BD ring cannot work properly anymore, because the
> > HW PIR and CIR are not the same after the re-initialization of the TX
> > BD ring.
> 
> I understand and I don't disagree that the TX BD ring doesn't work
> anymore if we disable it while it has pending frames (the TB0MR[EN]
> documentation says that this is unsafe too), but:
> - I don't understand why the hardware PIR and CIR are not the same after
>   the TX ring reinitialization
> - I don't understand how the effect and the claimed cause are connected
> 
> Could you please give more details what you mean here?

Currently, the hardware PIR and CIR are not initialized by the software
when the TX BD is re-initialized. The driver just reads HW PIR and CIR and
then initializes the SW PIR and CIR. See enetc_setup_txbdr():

/* clearing PI/CI registers for Tx not supported, adjust sw indexes */
tx_ring->next_to_use = enetc_txbdr_rd(hw, idx, ENETC_TBPIR);
tx_ring->next_to_clean = enetc_txbdr_rd(hw, idx, ENETC_TBCIR);

If there are unsent frames on the TX BD ring, the HW PIR and CIR are
not equal when the TX BD ring is disabled. So if the TX BD ring is
re-initialized at that time, the unsent frames will be freed and HW
PIR and CIR are still not equal after the re-initialization. At this point, 
the BDs between CIR and PIR are invalid, which will cause a hardware
malfunction.

Another reason is that there is internal context in the ring prefetch
logic that will retain the state from the first incarnation of the ring
and continue prefetching from the stale location when we re-initialize
the ring. The internal context is only reset by an FLR. That is to say,
for LS1028A ENETC, software cannot set the HW CIR and PIR when
initializing the TX BD ring.

The best solution is to either not initialize the TX BD ring or use FLR
to initialize it when this situation (the TX BD ring still has unsent
frames) occurs. Either approach involves complex modifications,
especially the FLR method. I don't have enough time to fix this issue
for the LS1028A. At least for now, this patch is what I can do, and it
doesn't conflict with subsequent solutions.