The ENETC does not support BUF_LEN or FRM_LEN in TX buffer descriptors less than 16. This is written in the reference manual of all SoCs supported by the driver: LS1028A, i.MX943, i.MX95 etc. Frames must not have a FRM_LEN that is less than 16 bytes. Frames of 0-15 bytes are not supported. (...) The first descriptor in a chain must not have a BUFF_LEN that is less than 16 bytes. I don't think proper attention was paid to this during development, we found the text at the end of a bug investigation. Therefore, the driver does not enforce this. But the frame length and geometry is out of the driver's control, and the network stack can actually send packets that ENETC doesn't like. Zefir Kurtisi found a case where transmitting L2 WNM keep-alive frames through ENETC would soft-lockup the host through an IRQ storm. He later distilled this into a small enetc-killer.c user space program which sends a packet with MAC DA, MAC SA and EtherType IPv4 (14 octets in length) through an AF_PACKET raw socket. Note that this particular case was already closed by the previous commit, but an identical situation still happens when the first buffer of a multi-buffer frame is < 16 bytes. The IRQ storm is actually a curious effect of a chain of events. The hardware behaviour, when an invalid BD is put in its TX ring, is that it would transmit the packet as normal, update counters, raise completion interrupt as normal, but it would just not advance the consumer index of the ring (TBaCIR) to signify that the BD has been consumed and is available for software to free. The ring will also get its TBaSR[BUSY] bit persistently set to 1 afterwards. It deserves an explanation why the behaviour above would lead to an IRQ storm, since ENETC interrupts are message-based (MSI-X), and an unhandled interrupt would typically just be lost rather than retrigger itself as a wired interrupt would. NAPI processing in ENETC has 3 steps: I. the enetc_msix() hardirq handler disables RBaIER, TBaIER and sets softirq processing to the 'pending' state. II. the enetc_poll() softirq handler for the IRQ vector walks through the TX rings affine to that vector, checks which ones have a TBCIR updated since last time - enetc_bd_ready_count() - processes those completed frames, and clears pending interrupts in these updated TX rings by writing to TBaIDR. (I've excluded RX processing due to it being irrelevant). III. After the softirq handler does its round of checking all RX and TX rings for updates, it re-enables all interrupts in RBaIER and TBaIER that were previously disabled by the hardirq handler, and exits. Because the TX ring with the short frame is skipped at step II (TBCIR wasn't updated as part of HW malfunction), its pending IRQ is not cleared in TBaIDR by enetc_clean_tx_ring(). But because enetc_msix() disables TBaIER at step I and re-enables it at step III, another MSI will be fired upon re-enabling it. This is what completes the cycle and the driver goes back to step I. So the driver misinterprets the mixed signals it's getting from the hardware, and ends up causing a software-amplified IRQ storm. Because the driver now pads linear skbs to ETH_ZLEN for other reasons too, we just need to ensure the head buffer has at least 16 bytes. This can be done using pskb_may_pull(), which moves that number of bytes from the paged area into the head. This is case 5 below. skb_headlen (H) | skb->len (L) | linear? | handled by ----------------+--------------+---------+--------------------------------------- H == L | L < 60 | yes | eth_skb_pad() (pads head to 60) H == L | L >= 60 | yes | already valid, no-op H < 16 | L < 60 | no | eth_skb_pad() (linearizes + pads to 60) H < 16 | L >= 60 | no | pskb_may_pull() (pulls frags into head) H >= 16 | L >= 60 | no | already valid, no-op Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") Reported-by: Zefir Kurtisi Closes: https://lore.kernel.org/netdev/b3d9136c-2803-4203-b1ea-1f9e62de80a1@gmail.com/ Signed-off-by: Vladimir Oltean --- v4->v5: none v3->v4: - rename from "net: enetc: pad short frames in software". The padding to ETH_ZLEN is now done by "net: enetc: do not rely on mEMAC hardware frame padding", so this patch only deals with the 16 octet minimum head buffer length - move the check from enetc_xmit() to enetc_start_xmit(), after eth_skb_pad() - use pskb_may_pull() instead of skb_linearize() - drop the code comment above the head buffer length check, it is redundant with the commit message - rework the commit message, add a table of the handled cases - drop Reviewed-by from Wei Fang and Tested-by from Zefir Kurtisi due to the change of approach v1->v3: part of "pad short frames in software" --- drivers/net/ethernet/freescale/enetc/enetc.c | 6 ++++++ drivers/net/ethernet/freescale/enetc/enetc.h | 2 ++ 2 files changed, 8 insertions(+) diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c index a9ea124f7835..58a88f15fa5d 100644 --- a/drivers/net/ethernet/freescale/enetc/enetc.c +++ b/drivers/net/ethernet/freescale/enetc/enetc.c @@ -1088,6 +1088,12 @@ static netdev_tx_t enetc_start_xmit(struct sk_buff *skb, if (eth_skb_pad(skb)) return NETDEV_TX_OK; + if (unlikely(skb_headlen(skb) < ENETC_MIN_BUFF_SIZE && + !pskb_may_pull(skb, ENETC_MIN_BUFF_SIZE))) { + dev_kfree_skb_any(skb); + return NETDEV_TX_OK; + } + if (unlikely(skb_shinfo(skb)->nr_frags > priv->max_frags)) if (unlikely(skb_linearize(skb))) goto drop_packet_err; diff --git a/drivers/net/ethernet/freescale/enetc/enetc.h b/drivers/net/ethernet/freescale/enetc/enetc.h index db3b3bad0f59..6fc7001c025c 100644 --- a/drivers/net/ethernet/freescale/enetc/enetc.h +++ b/drivers/net/ethernet/freescale/enetc/enetc.h @@ -22,6 +22,8 @@ #define ENETC_MAX_MTU (ENETC_MAC_MAXFRM_SIZE - \ (ETH_FCS_LEN + ETH_HLEN + VLAN_HLEN)) +#define ENETC_MIN_BUFF_SIZE 16 + #define ENETC_CBD_DATA_MEM_ALIGN 64 #define ENETC_MADDR_HASH_TBL_SZ 64 -- 2.43.0