Re: [PATCH] net: enetc: fix sirq-storm by clearing IDR registers

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Thu, Feb 26, 2026 at 08:28:53PM +0100, Zefir Kurtisi wrote:
> Thank you for the feedback and clarifications.
> 
> The statement that SITXIDR/SIRXIDR bits are directly linked to TBaIDR/RBaIDR
> is missing in the reference manual, i.e. it states that the former represent
> a summary of the latter, but not that W1C-ing the bits in SITXIDR would also
> move the other direction and clear TBaIDR. That clarifies quite a bit,
> thanks.
> 
> As for your request to take the mainline branch, I am depending on a OpenWRT
> build-system and shifting linux kernel-versions is unfortunately not
> something I can do in no time. As for the potentially missing patch you
> pointed me to, I backported that one, but it makes no difference.
> 
> Luckily meanwhile I was able to narrow down the issue and can provide you a
> means to hopefully reproduce it. This is the tl;dr version:
> 
> * enetc operates eth0
> * ath9k operates wlan0
> * both are bridged over OVS
> * device is AP with an active STA connected to it
> * STA regularly sends an L2 WNM keep-alive frame
>  * that frame is 'buggy' as being tagged IPv4 but without payload
> * through the OVS bridge that frame makes it into eth0 TX path
> * enetc_start_xmit() enqueues it into TX-BD
> * HW processes that descriptor, sets IDR and issues interrupt
> * enetc_clean_tx_ring()
>  * gets a bds_to_clean=0 (tx_ring->tcir = tx_ring->next_to_clean)
>   * i.e. HW signals it completed the BD but did not advance TCIR
>  * skips the while() loop
>  * and hence never clears the according SITXIDR bit
> * enetc_poll() after completion of ring processing
>  * re-enables interrupts
>  * but the one bit in SITXIDR is now sticky
> * interrupt is re-asserted immediately
> * the affected core remains 100% SIRQing
> * it only recovers when the affected TX ring advances
> 
> So in short, enetc breaks when sending 0-byte frames.
> 
> The patch that I provided resolves the problem by force-cleaning all IDRs
> before interrupts are re-enabled. That is the sledge-hammer approach, since
> it also unmasks BDs that were just completed during
> execution of enetc_poll() or no_eof BDs. Hence it is not the final
> solution, but currently anything is better than a freezing box.
> 
> Below is the tool I wrote to fire such a frame-of-death. If you can
> reproduce the observation, I'd prepare a v2 patch to unblock the issue once
> it happens - preventing enetc_start_xmit() from sending such frames I'd
> leave to you, since that part looks complex to me to handle it properly.
> 
> 
> Cheers,
> Zefir
> 
> ---
> 
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <net/ethernet.h>
> #include <netpacket/packet.h>
> #include <net/if.h>
> #include <arpa/inet.h>
> #include <sys/ioctl.h>
> 
> /*
>  * Enetc-Killer
>  *
>  * This is a PoC for fsl_enetc Ethernet driver to detect an
>  * issue the driver has when zero-payload IP packets are sent.
>  *
>  * It was detected when using an enetc Ethernet interface bridged
>  * with a wireless interface operating as AP. A connected client
>  * regularly sends L2 WNM keep-alive frames without IP payload.
>  * Through the bridge this 'buggy' packet makes it into the
>  * enetc TX path, which the driver enqueues for sending and
>  * the HW signals transmission done but without providing a
>  * completed TX-BD. This leads to a sticky interrupt detected
>  * flag causing a SIRQ-storm.
>  *
>  * This has been tested on a LS1028A based system under an
>  * OpenWRT derivative / linux 6.6.93
>  *
>  * To test:
>  * * build and copy binary to device
>  * * connect over serial, leave eth0 idle
>  * * ensure device runs with multiple cores enabled (otherwise it freezes)
>  * * run the program
>  * * with top, observe that one core is fully loaded with SIRQ
>  * * to recover, storm-ping eth0 from outside to
>  *   enforce TX-BD advance
>  */
> 
> int main()
> {
> 	int sock = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
> 	if (sock < 0) {
> 		perror("socket");
> 		return 1;
> 	}
> 
> 	struct ifreq ifr;
> 	memset(&ifr, 0, sizeof(ifr));
> 	strncpy(ifr.ifr_name, "eth0", IFNAMSIZ);
> 	if (ioctl(sock, SIOCGIFINDEX, &ifr) < 0) {
> 		perror("ioctl");
> 		return 1;
> 	}
> 
> 	struct sockaddr_ll addr = { 0 };
> 	addr.sll_family = AF_PACKET;
> 	addr.sll_ifindex = ifr.ifr_ifindex;
> 	addr.sll_halen = ETH_ALEN;
> 	addr.sll_protocol = htons(ETH_P_IP);
> 	// Destination MAC (Broadcast)
> 	addr.sll_addr[0] = 0xff;
> 	addr.sll_addr[1] = 0xff;
> 	addr.sll_addr[2] = 0xff;
> 	addr.sll_addr[3] = 0xff;
> 	addr.sll_addr[4] = 0xff;
> 	addr.sll_addr[5] = 0xff;
> 
> 	// "broken" packet: only Ethernet-header, no IP-payload
> 	// as sent by wpa_supplicant as L2 WNM keep-alive frame
> 	unsigned char buf[14] = {
> 		0xff, 0xff, 0xff, 0xff, 0xff, 0xff,	// DST MAC
> 		0x00, 0x11, 0x22, 0x33, 0x44, 0x55,	// SRC MAC
> 		0x08, 0x00				// EtherType = IPv4
> 	};
> 
> 	if (sendto(sock, buf, sizeof(buf), 0, (struct sockaddr*) &addr,
> sizeof(addr)) < 0) {
> 		perror("sendto");
> 		return 1;
> 	}
> 	close(sock);
> 	return 0;
> }
> 

If I understand correctly, this patch should resolve your issue?

From 887cf74648fb10b7dee3c60199349d184c5a851e Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Thu, 26 Feb 2026 21:50:13 +0200
Subject: [PATCH] net: enetc: avoid sending too short Ethernet frames

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/ethernet/freescale/enetc/enetc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index b0b47b0f7723..4f5e593b348a 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -982,6 +982,9 @@ static netdev_tx_t enetc_start_xmit(struct sk_buff *skb,
 	struct enetc_bdr *tx_ring;
 	int count;
 
+	if (eth_skb_pad(skb))
+		return NETDEV_TX_OK;
+
 	/* Queue one-step Sync packet if already locked */
 	if (enetc_cb->flag & ENETC_F_TX_ONESTEP_SYNC_TSTAMP) {
 		if (test_and_set_bit_lock(ENETC_TX_ONESTEP_TSTAMP_IN_PROGRESS,
-- 
2.43.0