From: "Théo Lebrun" <theo.lebrun@bootlin.com>
To: "Théo Lebrun" <theo.lebrun@bootlin.com>,
"Conor Dooley" <conor.dooley@microchip.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@kernel.org>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Richard Cochran" <richardcochran@gmail.com>,
"Russell King" <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"Paolo Valerio" <pvalerio@redhat.com>,
"Nicolai Buchwitz" <nb@tipi-net.de>,
"Vladimir Kondratiev" <vladimir.kondratiev@mobileye.com>,
"Gregory CLEMENT" <gregory.clement@bootlin.com>,
"Benoît Monin" <benoit.monin@bootlin.com>,
"Tawfik Bayouk" <tawfik.bayouk@mobileye.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
stable+noautosel@kernel.org, Sashiko <sashiko-bot@kernel.org>
Subject: [PATCH net-next v11 1/9] net: macb: close race between NAPI polls & ndo_stop
Date: Tue, 13 Oct 2026 15:16:39 +0200 [thread overview]
Message-ID: <20261013-macb-context-v11-1-b27785167566@bootlin.com> (raw)
In-Reply-To: <20261013-macb-context-v11-0-b27785167566@bootlin.com>
In ndo_close, we call napi_disable() then free the ring buffers
queue->rx_ring|tx_ring. In the NAPI poll functions, after
napi_complete_done() we might enable interrupts and might re-check the
next ring buffer slot.
This is a use-after-free race on our ring buffers because napi_disable()
only waits for napi_complete_done() to return, it does not wait for
NAPI poll functions to finish.
The poll function sequence must stay as-is, see commit 0bf476fc3624
("net: macb: Fix lost RX packet wakeup race in NAPI receive") which
explains why the sequence must be napi_complete_done() -> arm IRQs
-> re-check ring slot.
Fix by waiting for full end of NAPI poll functions using
synchronize_net() in our ndo_close implementation.
This bug has never been reproduced and was reported by Sashiko. The
chances of facing it in practice sound tiny: it needs a system without
any phylink attached, running PREEMPT_RT and with a kernel preemption
on the NAPI poll at the right instant.
We fix it here before introducing context swapping, which is another
place where the race could appear (and Sashiko complains on this
series).
Fixes: 138badbc21a0 ("net: macb: use NAPI for TX completion path")
Fixes: 1900e30d0ef7 ("net: macb: simplify/cleanup NAPI reschedule checking")
Cc: stable+noautosel@kernel.org # too unlikely and never reported by users
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261001-macb-context-v10-0-beb541bbb7df%40bootlin.com?part=7
Link: https://lore.kernel.org/all/179115680572.434549.1016291990685937691@kernel.org/
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
drivers/net/ethernet/cadence/macb_main.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 020a47353d01..d414d00d93ce 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2059,6 +2059,12 @@ static void macb_quiesce_start(struct macb *bp)
napi_disable(&queue->napi_tx);
}
+ /* NAPI instances still access Rx/Tx rings after their
+ * napi_complete_done() calls! Callers to macb_quiesce_start()
+ * free rings, so wait for all NAPI handlers to be done.
+ */
+ synchronize_net();
+
/* Must be done after napi_tx is disabled: its completion re-arms
* the LPI timer.
*/
--
2.56.0
next prev parent reply other threads:[~2026-10-13 13:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 13:16 [PATCH net-next v11 0/9] net: macb: implement context swapping Théo Lebrun
2026-10-13 13:16 ` Théo Lebrun [this message]
2026-10-13 13:54 ` [PATCH net-next v11 1/9] net: macb: close race between NAPI polls & ndo_stop Nicolai Buchwitz
2026-10-13 13:16 ` [PATCH net-next v11 2/9] net: macb: introduce macb_context struct for buffer management Théo Lebrun
2026-10-13 13:16 ` [PATCH net-next v11 3/9] net: macb: avoid macb_init_rx_buffer_size() modifying state Théo Lebrun
2026-10-13 13:16 ` [PATCH net-next v11 4/9] net: macb: make `struct macb` subset reachable from macb_context struct Théo Lebrun
2026-10-13 13:16 ` [PATCH net-next v11 5/9] net: macb: change caps helpers signatures Théo Lebrun
2026-10-13 13:16 ` [PATCH net-next v11 6/9] net: macb: change function signatures to take contexts Théo Lebrun
2026-10-13 13:16 ` [PATCH net-next v11 7/9] net: macb: introduce macb_context_alloc() helper Théo Lebrun
2026-10-13 13:16 ` [PATCH net-next v11 8/9] net: macb: use context swapping in .set_ringparam() Théo Lebrun
2026-10-13 13:16 ` [PATCH net-next v11 9/9] net: macb: use context swapping in .ndo_change_mtu() Théo Lebrun
2026-10-13 13:20 ` [PATCH net-next v11 0/9] net: macb: implement context swapping netdev-bot+sinfo
2026-10-13 13:29 ` Théo Lebrun
2026-10-13 19:04 ` Nicolai Buchwitz
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=20261013-macb-context-v11-1-b27785167566@bootlin.com \
--to=theo.lebrun@bootlin.com \
--cc=andrew+netdev@lunn.ch \
--cc=benoit.monin@bootlin.com \
--cc=conor.dooley@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=gregory.clement@bootlin.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=nb@tipi-net.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pvalerio@redhat.com \
--cc=richardcochran@gmail.com \
--cc=sashiko-bot@kernel.org \
--cc=stable+noautosel@kernel.org \
--cc=tawfik.bayouk@mobileye.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vladimir.kondratiev@mobileye.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