From: Sagi Maimon <maimon.sagi@gmail.com>
To: netdev@vger.kernel.org
Cc: radhey.shyam.pandey@amd.com, michal.simek@amd.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, linux@armlinux.org.uk,
daniel@iogearbox.net, andybnac@gmail.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Sagi Maimon <maimon.sagi@gmail.com>
Subject: [PATCH net v2 2/4] net: axienet: quiesce the TX path before axienet_stop() tears it down
Date: Thu, 24 Sep 2026 16:51:14 +0300 [thread overview]
Message-ID: <20260924135116.185161-3-maimon.sagi@gmail.com> (raw)
In-Reply-To: <20260924135116.185161-1-maimon.sagi@gmail.com>
On the legacy DMA path axienet_stop() stops the DMA engine and frees the
TX descriptor ring with axienet_dma_bd_release(), but never stops the
transmit queue or waits for a transmit already in progress.
On the dev_close() path this is covered by the core:
dev_deactivate_many() has already quiesced the qdisc and waited for
in-flight transmits with synchronize_net(). axienet_suspend() instead
calls axienet_stop() directly. Its netif_device_detach() only sets
__QUEUE_STATE_DRV_XOFF, without taking the transmit lock, so an
axienet_start_xmit() that was already running can still be writing a
descriptor into lp->tx_bd_v, or kicking XAXIDMA_TX_TDESC, while the
engine is reset and the ring is freed underneath it.
Call netif_tx_disable() once TX NAPI is disabled and the error work has
been flushed. It takes each queue's transmit lock, so it waits for any
transmit in progress, and nothing can wake the queue afterwards: the
error work returns early once lp->stopping is set, and axienet_tx_poll()
can no longer run.
The dmaengine path is left as it is. There the completion callback can
wake the queue until the channel has been terminated, so it would need a
different ordering.
Tested on an AXI Ethernet MAC behind a PCIe endpoint: traffic passes,
and after each of ten down/up cycles and five module reloads, all made
with traffic running and each running this path, traffic resumes and
nothing is logged. Suspend was not exercised.
Fixes: a3de357b087e ("net: axiemac: add PM callbacks to support suspend/resume")
Assisted-by: LLM sparse
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index fb26d2e39fac..6d448d0b523d 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1739,6 +1739,14 @@ static int axienet_stop(struct net_device *ndev)
napi_disable(&lp->napi_tx);
napi_disable(&lp->napi_rx);
+
+ /* Nothing can wake the queue now: the error work returns early
+ * once lp->stopping is set, and TX NAPI is disabled. Stop it and
+ * wait out any transmit in progress before the ring goes away.
+ * dev_close() has already done this, but axienet_suspend() calls
+ * us directly.
+ */
+ netif_tx_disable(ndev);
}
cancel_work_sync(&lp->rx_dim.work);
--
2.47.0
next prev parent reply other threads:[~2026-09-24 13:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 13:51 [PATCH net v2 0/4] net: axienet: fix TX queue handling around a DMA error reset Sagi Maimon
2026-09-24 13:51 ` [PATCH net v2 1/4] net: axienet: start the TX queue in axienet_open() Sagi Maimon
2026-09-24 13:51 ` Sagi Maimon [this message]
2026-09-24 13:51 ` [PATCH net v2 3/4] net: axienet: quiesce the TX queue across a DMA error reset Sagi Maimon
2026-09-24 13:51 ` [PATCH net v2 4/4] net: axienet: reprogram the link settings after " Sagi Maimon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260924135116.185161-3-maimon.sagi@gmail.com \
--to=maimon.sagi@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=andybnac@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=michal.simek@amd.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=radhey.shyam.pandey@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®