Hello Jakub,
On Thu Oct 8, 2026 at 1:22 AM CEST, Jakub Kicinski wrote:
On Sun, 04 Oct 2026 23:33:24 +0000 netdev-bot+sashiko@kernel.org wrote:
quoted
- [Medium] The NAPI poll handlers read the context after
napi_complete_done(), and nothing stops that context from being freed…
Looks legit at the surface. I was going to try to double check and
then realized the series no longer applies :S
Yes that report was correct!
napi_disable() only waits for napi_complete_done() to be called,
but our poll functions still dereference the rings after the
napi_complete_done() call.
That's an issue for all drivers (quite a few are broken in that sense).
I see two solutions:
- Avoid all dangerous reads in NAPI poll after napi_complete_done().
- Wait for full NAPI poll to be done using synchronize_net().
We cannot use the first solution in MACB as we must re-read rings after
unmasking IRQs to check if we lost a wakeup signal, see commit
0bf476fc3624 ("net: macb: Fix lost RX packet wakeup race in NAPI
receive"). So we'll take the second one.
This bug is unrelated to context swapping though; the upstream driver
already has the same race condition. Sashiko rather funnily attributes
it to our series; somehow the use-after-free got more serious.
I checked for precedent as I would have been surprised we were the first
ones to land in that napi_disable() subtlety. See commit eb41a264a3a5
("net/mlx5e: Fix race between DIM disable and net_dim()") which uses the
synchronize_net() mechanism to prevent against the exact same race.
V11 has been sent already, see:
[PATCH net-next v11 1/9] net: macb: close race between NAPI polls & ndo_stop
https://lore.kernel.org/netdev/20261013-macb-context-v11-1-b27785167566@bootlin.com/ (local)
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com