From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 73FB0CA600A for ; Thu, 8 Oct 2026 07:55:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=nOGGehV28daWJf9qST4Dzu/SVjt55hUykjS1Zi7cwqQ=; b=1t1MfgkC+M60d3eNLeoapT3HZh IJoVUrQv62cfgdZq8DdedX9UILjs9hqMkEnjse81OcLdrHVegrTY5Y8tjqFFknskh/rjGBkRb1mHZ 3AqL43jKRwZhIuZuzmD+G+BXjxJ0VgTykhMfYjoud1kHkRnuwYP0TTAfcQNWbmrc5pTgEreoHXizd Gw76v+kmFPXBwfs55FnGoHv8Tiw21zCAG9J+7oAJvDtvcQ6Sdflulx4IKzzEY3FGssAM+z2kmzAR5 PBYI34Qr08BbwKny4YWaXihYNivsk8cvpS19mqIeqyOt3jdUhciqoxcJIfLsHmB66aR2MFENddyTH LSxkO2Mw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEixu-00000003nog-3wSC; Thu, 08 Oct 2026 07:54:58 +0000 Received: from mail.tipi-net.de ([194.13.80.246]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEixt-00000003noF-0whT for linux-arm-kernel@lists.infradead.org; Thu, 08 Oct 2026 07:54:58 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 36771A0957; Thu, 8 Oct 2026 09:54:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tipi-net.de; s=dkim; t=1791446093; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=nOGGehV28daWJf9qST4Dzu/SVjt55hUykjS1Zi7cwqQ=; b=knH70O9LDJSwXk48ooaH+Tm2qArFPgIhLyTzJz9WArPWgBeXhXWeI7Bt6sYLQAdLVXi+tB S6AL9rDE7A3F7wLYXSqLBxH3SjYuDneqPyQBkg4eC3q+TRjYpgTtPz3stYesNR64BFDY6R QNwdFOid4C/K1rNvj+wgK+qOm0hkUcMjeGJsE2STHGeLN0lWlrYcaQVSPpG8u9z5/KSHEz i2jWxbSPZSiRh739Upf/mspgNO/lFBGFT1ZRNMihRml8Z/sQ8H3ku1SU7WQP62MbLd83ty XqJVVJe7PRReJfmHj1NS+Vc7ErprwvoCe2BWzhNLTgXeT7XbfTzS5t/k39OcAQ== MIME-Version: 1.0 Date: Thu, 08 Oct 2026 09:54:52 +0200 From: Nicolai Buchwitz To: Kurt Kanzenbach Cc: Maxime Chevallier , Andrew Lunn , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Eric Dumazet , Maxime Coquelin , Alexandre Torgue , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , Song Yoong Siang , Noor Azura Ahmad Tarmizi , Mohd Faizal Abdul Rahim , Ong Boon Leong , Sebastian Andrzej Siewior , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org Subject: Re: [PATCH net v2 2/2] net: stmmac: Stop Tx queue when (en|dis)abling XSK pools In-Reply-To: <20261005-stmmac_xsk_crashes-v2-2-46c60cba6421@linutronix.de> References: <20261005-stmmac_xsk_crashes-v2-0-46c60cba6421@linutronix.de> <20261005-stmmac_xsk_crashes-v2-2-46c60cba6421@linutronix.de> Message-ID: <377d56dbc9be2874af7369112d9e49b9@tipi-net.de> X-Sender: nb@tipi-net.de Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20261008_005457_418775_E994E8E5 X-CRM114-Status: GOOD ( 19.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Kurt On 5.10.2026 09:09, Kurt Kanzenbach wrote: > When enabling or disabling XSK pools in parallel to Tx traffic, kernel > crashes occur. For VLAN tagged frames that happens in stmmac_xmit() -> > dwmac4_set_vlan_tag() and for normal frames in stmmac_xmit() -> > dwmac4_set_addr(). Both of these functions access the Tx DMA > descriptors. > > The XDP pool (en|dis)ablement frees and reallocates the Tx DMA > resources: > > stmmac_disable_tx_queue: > __free_dma_tx_desc_resources > > stmmac_enable_tx_queue: > __alloc_dma_tx_desc_resources > __init_dma_tx_desc_rings > > NAPI is disabled during that allocation window, but the Tx queue is not > stopped. Therefore, add the stopping of the Tx queue during the > enabling > and disabling of XSK pools. Update trans_start when stopping the queue > to avoid spurious watchdog timeouts. > > The issue can be easily reproduced by: > > 1. Run iperf > 2. Run application which opens an AF_XDP/ZC socket > > Fixes: 132c32ee5bc0 ("net: stmmac: Add TX via XDP zero-copy socket") > Signed-off-by: Kurt Kanzenbach > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c > b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c > index d7e4db7224b0..883bd3fe8089 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c > @@ -6,6 +6,16 @@ > #include "stmmac.h" > #include "stmmac_xdp.h" > > +static void stmmac_xdp_stop_tx_queue(struct stmmac_priv *priv, u16 > queue) > +{ > + struct netdev_queue *nq = netdev_get_tx_queue(priv->dev, queue); > + > + __netif_tx_lock_bh(nq); > + txq_trans_cond_update(nq); > + netif_tx_stop_queue(nq); > + __netif_tx_unlock_bh(nq); > +} > + > static int stmmac_xdp_enable_pool(struct stmmac_priv *priv, > struct xsk_buff_pool *pool, u16 queue) > { > @@ -36,6 +46,7 @@ static int stmmac_xdp_enable_pool(struct stmmac_priv > *priv, > if (need_update) { > napi_disable(&ch->rx_napi); > napi_disable(&ch->tx_napi); > + stmmac_xdp_stop_tx_queue(priv, queue); Unfortunately XDP_TX and ndo_xdp_xmit() ignore the stopped queue and still hit the freed ring. I can reproduce this on STM32MP215 with a veth redirect into the port while toggling the pool: pc : dwmac4_set_addr+0x8/0x18 lr : stmmac_xdp_xmit_xdpf+0x1d0/0x3f0 stmmac_xdp_xmit+0xe4/0x1a8 bq_xmit_all+0xa0/0x208 __dev_flush+0x60/0xc0 xdp_do_flush+0x134/0x198 veth_poll+0x258/0x340 Both go through stmmac_xdp_xmit_xdpf() with the queue lock held, so this fixes it for me: --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ static int stmmac_xdp_xmit_xdpf(struct stmmac_priv *priv, int queue, dma_addr_t dma_addr; bool set_ic; + /* Ring may be torn down for an XSK pool switch */ + if (netif_tx_queue_stopped(netdev_get_tx_queue(priv->dev, queue))) + return STMMAC_XDP_CONSUMED; + if (stmmac_tx_avail(priv, queue) < STMMAC_TX_THRESH(priv)) return STMMAC_XDP_CONSUMED; This is older than your patch, but could you fold it in / add a oatch? > [...] Thanks, Nicolai