Re: [PATCH net-next v10 1/8] net: macb: introduce macb_context struct for buffer management

["Théo Lebrun" <theo.lebrun@bootlin.com>]

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:
>> - [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/

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com