From: vladimir.oltean@nxp.com
To: netdev@vger.kernel.org
Cc: Zefir Kurtisi <zefir.kurtisi@westermo.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Wei Fang <wei.fang@nxp.com>, Clark Wang <xiaoning.wang@nxp.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Stanislav Fomichev <sdf@fomichev.me>,
Simon Horman <horms@kernel.org>,
Richard Cochran <richardcochran@gmail.com>,
Yangbo Lu <yangbo.lu@nxp.com>,
Ioana Ciornei <ioana.ciornei@nxp.com>,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org
Subject: [PATCH v3 net 7/7] net: enetc: drain and cancel one-step TX tstamp queue when going down
Date: Wed, 16 Sep 2026 01:27:34 +0300 [thread overview]
Message-ID: <20260915222735.1016937-8-vladimir.oltean@nxp.com> (raw)
In-Reply-To: <20260915222735.1016937-1-vladimir.oltean@nxp.com>
The driver uses a work item on the system workqueue
(priv->tx_onestep_tstamp) for deferred transmission of packets with
one-step TX timestamping requests. The reason is that the MAC supports
a single such packet in flight, but we cannot block the rate at which
user space enqueues them.
The problem is that the skb queue is never explicitly drained, and it
can hold packets even after the interface goes down or (worse) the
driver is unbound from the device. Especially the last point is
critical, because the work item will attempt to use freed data
structures of the netdev.
The priv->tx_onestep_tstamp work item (enetc_tx_onestep_tstamp)
processes one item from the priv->tx_skbs queue at a time, and gets
rescheduled on each one-step PTP packet TX completion.
If we cancelled the work item while NAPI was still enabled, there would
be no guarantee that NAPI would not reenable it. So the cancellation
needs to be after napi_disable().
Cancelling the work item waits for enetc_tx_onestep_tstamp() to finish
sending the current packet if already scheduled. The packet will be put
in the disabled TX BD ring, where nothing will happen with it until
enetc_free_rxtx_rings() later reclaims its memory (*).
However, priv->tx_skbs may contain more packets than just this one, and
because NAPI is disabled, enetc_clean_tx_ring() is unable to take care
of the rest. So we still have to clean up the remainder from the queue
and reset the ENETC_TX_ONESTEP_TSTAMP_IN_PROGRESS flag back for use.
On driver unbind, the problem should be solved by virtue of the fact
that unregister_netdev() calls netif_close_many() and that triggers this
same code path.
(*) Even if we add a check for ENETC_TX_DOWN in enetc_tx_onestep_tstamp(),
it is unavoidable that racing one-step PTP packets will be enqueued in a
disabled TX ring. This is because the work item runs asynchronously and
can miss that flag getting set. Think below:
CPU A CPU B
enetc_tx_onestep_tstamp()
-> test_bit(ENETC_TX_DOWN)
// says not down
enetc_stop()
-> set_bit(ENETC_TX_DOWN)
-> enetc_wait_bdrs()
// waits for the BDs in the
// ring to be transmitted,
// but the PTP frame is
// still queued in software
-> enetc_disable_tx_bdrs()
-> enetc_start_xmit()
So I don't see any point in adding an ENETC_TX_DOWN test in the work
item.
Fixes: 7294380c5211 ("enetc: support PTP Sync packet one-step timestamping")
Reported-by: Wei Fang <wei.fang@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v2->v3: patch is new
---
drivers/net/ethernet/freescale/enetc/enetc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index 62cdcaab3f3f..892490ff1ebe 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -3110,6 +3110,10 @@ void enetc_stop(struct net_device *ndev)
napi_disable(&priv->int_vector[i]->napi);
}
+ cancel_work_sync(&priv->tx_onestep_tstamp);
+ skb_queue_purge(&priv->tx_skbs);
+ clear_bit_unlock(ENETC_TX_ONESTEP_TSTAMP_IN_PROGRESS, &priv->flags);
+
enetc_clear_interrupts(priv);
}
EXPORT_SYMBOL_GPL(enetc_stop);
--
2.43.0
next prev parent reply other threads:[~2026-09-15 22:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 22:27 [PATCH v3 net 0/7] Fix short frame transmission in enetc vladimir.oltean
2026-09-15 22:27 ` [PATCH v3 net 1/7] net: enetc: consistenly track dropped frames in enetc_xdp_xmit() vladimir.oltean
2026-09-16 2:16 ` Wei Fang
2026-09-18 10:27 ` Vladimir Oltean
2026-09-16 23:35 ` netdev-bot+sashiko
2026-09-15 22:27 ` [PATCH v3 net 2/7] net: enetc: ensure enetc_xdp_xmit() calls enetc_update_tx_ring_tail() vladimir.oltean
2026-09-16 2:20 ` Wei Fang
2026-09-16 23:35 ` netdev-bot+sashiko
[not found] ` <20260916222806.6011F1F00893@smtp.kernel.org>
2026-09-18 23:05 ` Vladimir Oltean
2026-09-15 22:27 ` [PATCH v3 net 3/7] net: enetc: fix bogus TX ring consumer index after reinitialization vladimir.oltean
2026-09-15 22:27 ` [PATCH v3 net 4/7] net: enetc: pad short frames in software vladimir.oltean
2026-09-16 23:35 ` netdev-bot+sashiko
2026-09-17 10:11 ` David Laight
2026-09-21 11:29 ` Vladimir Oltean
2026-09-15 22:27 ` [PATCH v3 net 5/7] net: enetc: pad short XDP frames coming from devmap vladimir.oltean
2026-09-16 23:35 ` netdev-bot+sashiko
2026-09-15 22:27 ` [PATCH v3 net 6/7] net: enetc: linearize PTP event packets with one-step TX timestamping vladimir.oltean
2026-09-16 1:59 ` Wei Fang
2026-09-16 9:50 ` Vladimir Oltean
2026-09-16 23:35 ` netdev-bot+sashiko
2026-09-15 22:27 ` vladimir.oltean [this message]
2026-09-16 23:36 ` [PATCH v3 net 7/7] net: enetc: drain and cancel one-step TX tstamp queue when going down netdev-bot+sashiko
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=20260915222735.1016937-8-vladimir.oltean@nxp.com \
--to=vladimir.oltean@nxp.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=claudiu.manoil@nxp.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=imx@lists.linux.dev \
--cc=ioana.ciornei@nxp.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=sdf@fomichev.me \
--cc=wei.fang@nxp.com \
--cc=xiaoning.wang@nxp.com \
--cc=yangbo.lu@nxp.com \
--cc=zefir.kurtisi@westermo.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