[PATCH net v2] net: stmmac: Disable queues before netif_tx_disable in xdp_release

[PATCH net v2] net: stmmac: Disable queues before netif_tx_disable in xdp_release

[muhammad.nazim.amirul.nazle.asmade]

From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>

stmmac_xdp_release() calls netif_tx_disable() while NAPI is still
running. A TX completion handled in NAPI context can then restart the
queue through netif_tx_wake_queue() in stmmac_tx_clean(), so the stack
may call ndo_start_xmit() while the DMA rings are being torn down,
leading to a kernel panic.

Fix this by disabling NAPI with stmmac_disable_all_queues() and
cancelling the TX timers before calling netif_tx_disable(). This
matches the teardown order already used in __stmmac_release() since
commit 7028471edb64 ("net: ethernet: stmicro: stmmac: first disable all
queues and disconnect in release"), so both release paths stop NAPI,
the TX timers and the TX queues in the same way.

Once NAPI is disabled, NAPI_STATE_SCHED stays set, so
stmmac_tx_timer_arm() takes the hrtimer_try_to_cancel() path and new
transmissions cannot re-arm the TX timers after hrtimer_cancel().

Fixes: 77711683a504 ("net: stmmac: ensure tx function is not running in stmmac_xdp_release()")
Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v2:
- Fix the Fixes: tag to point to the commit that introduced
  netif_tx_disable() in stmmac_xdp_release()
- Describe the queue wake-up race in the commit message, and why the
  TX timers cannot be re-armed after hrtimer_cancel() (Sashiko review)
- The other two issues reported by Sashiko (ndo_xdp_xmit() racing with
  stmmac_xdp_release(), and stmmac_xdp_set_prog() ignoring the
  stmmac_xdp_open() return value) are pre-existing and not affected by
  this change; they will be looked at separately.
- Rebase on latest net/main

v1: https://lore.kernel.org/netdev/20260727030645.13280-1-muhammad.nazim.amirul.nazle.asmade@altera.com/

 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7ffed295eb14..7d1497392b8b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7264,15 +7264,15 @@ void stmmac_xdp_release(struct net_device *dev)
 	struct stmmac_priv *priv = netdev_priv(dev);
 	u8 chan;
 
-	/* Ensure tx function is not running */
-	netif_tx_disable(dev);
-
 	/* Disable NAPI process */
 	stmmac_disable_all_queues(priv);
 
 	for (chan = 0; chan < priv->plat->tx_queues_to_use; chan++)
 		hrtimer_cancel(&priv->dma_conf.tx_queue[chan].txtimer);
 
+	/* Ensure tx function is not running */
+	netif_tx_disable(dev);
+
 	/* Free the IRQ lines */
 	stmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0);
 
-- 
2.43.7

Re: [PATCH net v2] net: stmmac: Disable queues before netif_tx_disable in xdp_release

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.