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