Re: [PATCH mt76] wifi: mt76: mt792x: drop redundant napi_disable() in unregister path

Mikhail Gavrilov <[email protected]> Tue, 4 Aug 2026 15:46:12 +0500
Newsgroups org.kernel.vger.linux-wireless,dev.linux.lists.regressions,org.kernel.vger.linux-kernel
Message-ID <CABXGCsOAK92WxxLyYVfVrdEdLwvZh0JK5RJHn7J0X0mtCD3bkQ@mail.gmail.com>
On Tue, Aug 4, 2026 at 2:29=E2=80=AFPM Thorsten Leemhuis <[email protected]=
fo> wrote:
>
> TWIMC, there is another report about reboot/shutdown problems with mt76
> that was bisected to the commit mentioned above:
> https://bugzilla.kernel.org/show_bug.cgi?id=3D221818
>
> Pointed the reporter to this proposed fix two days ago, but no reply yet.
>

Thanks for the pointer - but please do not point people at this patch:
it is withdrawn.  I asked for it to be dropped on Jul 30, which was
before you sent them here, so you would have had no way of knowing.

Eric Biggers found that it introduces a use-after-free.  With the early
napi_disable() loops gone, the RX poll can reach mt76_token_release()
via PKT_TYPE_TXRX_NOTIFY and mt7921_mac_tx_free() while
mt76_connac2_tx_token_put() is running idr_destroy(&dev->token) outside
token_lock:

  https://lore.kernel.org/all/20260730050428.GA73812@sol/

So it fixes the hang and replaces it with something worse.  The diagnosis
in the commit message still holds - the hang is a double napi_disable(),
which is not idempotent - only the choice of where to fix it was wrong.

I am posting a plain revert of 13b7e6a96a00 instead, as [PATCH wireless],
since the regression is now in its second week with four independent
reporters and nobody has objected to reverting.  That restores the WARNs
in __netif_napi_del_locked() and page_pool_disable_direct_recycling() on
mt7915e with an MT7916, which is what 13b7e6a96a00 was fixing, but a WARN
is a much smaller problem than a machine that will not reboot.

Doing it properly means adding napi_disable() inside the drivers that
delete the NAPI instances - mt7915_unregister_device() and friends -
rather than in the shared mt76_dma_cleanup() where the timing is forced.
I am leaving that part to Nicolas: MT7916 is what he reported against and
I do not have that hardware.

For the bugzilla reporter: the revert should apply cleanly on top of
current mainline, and I will follow up with the lore link once it is out.

--=20
Thanks,
Mikhail