[PATCH wireless] Revert "wifi: mt76: Disable napi when removing device"

[PATCH wireless] Revert "wifi: mt76: Disable napi when removing device"

[Mikhail Gavrilov]

This reverts commit 13b7e6a96a005c656d38f3da51581deaf9866375.

That commit made mt76_dma_cleanup() disable every RX NAPI instance before
deleting it, to silence WARNs in __netif_napi_del_locked() and
page_pool_disable_direct_recycling() seen when unloading mt7915e with an
MT7916.

On mt7921e and mt7925e the same instances are already disabled earlier,
in mt7921e_unregister_device() and mt7925e_unregister_device(), which
only afterwards call mt792x_dma_cleanup() -> mt76_dma_cleanup().  Each
instance is therefore disabled twice, and napi_disable() is not
idempotent: on return it leaves NAPIF_STATE_SCHED and NAPIF_STATE_NPSVC
set, so the second call spins in usleep_range() forever, waiting for bits
that nobody will clear.

mt7921_pci_shutdown() and mt7925_pci_shutdown() reuse the remove path, so
this is hit on every reboot, poweroff and module unload.  It is silent:
the stuck task keeps sleeping and rescheduling, so neither the hung task
detector nor the lockup detectors fire, and the last line on the console
is "systemd-shutdown[1]: Rebooting."

  task:modprobe        state:D stack:25720 pid:7954  tgid:7954
  Call Trace:
   <TASK>
   __schedule+0x11b8/0x26d0
   schedule+0xe7/0x2f0
   schedule_hrtimeout_range_clock+0x218/0x330
   usleep_range_state+0x133/0x1b0
   napi_disable_locked+0x37d/0x5f0
   napi_disable+0x43/0x80
   mt76_dma_cleanup+0x2b4/0x860 [mt76]
   mt7921_pci_remove+0x17f/0x350 [mt7921e]
   pci_device_remove+0xb6/0x1e0
   device_release_driver_internal+0x38d/0x540
   driver_detach+0xd0/0x1b0
   bus_remove_driver+0x127/0x2d0
   pci_unregister_driver+0x2a/0x280
   __do_sys_delete_module+0x36a/0x5b0
   do_syscall_64+0x11c/0x6d0
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
   </TASK>

Dropping the two driver-side loops instead was tried and rejected: with
them 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, which is a use-after-free rather than a hang [1].

Revert for now, so that reboot, poweroff and module unload work again.
The WARNs on mt7915e are a less severe problem than an unbootable
machine, and fixing them belongs in the drivers that delete the NAPI
instances, where each one can pick a point that is safe for its own
teardown order, rather than in the shared mt76_dma_cleanup().

Reported-by: Bert Karwatzki <spasswolf@web.de>
Closes: https://lore.kernel.org/all/20260724151419.26014-1-spasswolf@web.de/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221818
Link: https://lore.kernel.org/all/20260730050428.GA73812@sol/ [1]
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
---

Sending this because the regression is now in its second week with four
independent reporters, and the two-part alternative (this revert plus
napi_disable() added inside mt7915_unregister_device()) needs MT7916
hardware that I do not have.  I deliberately left the mt7915 side out;
Nicolas is best placed to do it, since MT7916 is what he reported
against.
 
Verified on 7.2.0-rc5 with KASAN and lockdep enabled, MT7922 / mt7921e:
before the revert 'modprobe -r mt7921e' hangs (backtrace above, taken
with sysrq-w) and the machine never gets past "Rebooting."; after it,
module unload and reload, reboot and poweroff all work again.
 
The hang was independently bisected to the same commit by Bert Karwatzki
on MT7925 and reproduced by Devin Wittmayer on MT7927 and MT7922, and
Eric Biggers saw it on mt7925e as well.

 drivers/net/wireless/mediatek/mt76/dma.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
index 322041859217..f8c2fe5f2f58 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -1189,10 +1189,7 @@ void mt76_dma_cleanup(struct mt76_dev *dev)
 	mt76_for_each_q_rx(dev, i) {
 		struct mt76_queue *q = &dev->q_rx[i];
 
-		if (!mt76_queue_is_wed_rro(q)) {
-			napi_disable(&dev->napi[i]);
-			netif_napi_del(&dev->napi[i]);
-		}
+		netif_napi_del(&dev->napi[i]);
 		mt76_dma_rx_cleanup(dev, q);
 
 		page_pool_destroy(q->page_pool);
-- 
2.55.0

Re: [PATCH wireless] Revert "wifi: mt76: Disable napi when removing device"

[Devin Wittmayer]

The revert works here. Module unload, reboot and poweroff all work again
on an MT7922 / mt7921e, and the USB path is unchanged.

Applied on top of 7.2-rc5 with PROVE_LOCKING on a second MT7922 /
mt7921e machine, independently confirming your result. Before the revert
the first rmmod never returns: D state, refcount -1, and the same stack
you posted, taken from /proc/pid/stack and sysrq-w. With it applied, 40
of 40 load and unload cycles finish with rmmod in 0.3-0.4 s, three more
with the interface associated and receive traffic in flight all finish
under a second, and a graceful reboot and a poweroff with the driver
bound both complete normally.

mt7921e disables the same instances in its suspend and reset paths as
well, so I ran three cycles of each and unloaded after every one, to be
sure those paths leave the instances in a state the remaining disable in
mt7921e_unregister_device() still handles. They do. No warnings and no
lockdep reports in any of these runs.

Same host and kernel, USB control: mt7925u reaches mt76u_queues_deinit()
rather than mt76_dma_cleanup(), and 10 of 10 cycles on each side of the
revert behave the same.

Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>

Re: [PATCH wireless] Revert "wifi: mt76: Disable napi when removing device"

[Thorsten Leemhuis]

On 8/4/26 14:00, Mikhail Gavrilov wrote:
> This reverts commit 13b7e6a96a005c656d38f3da51581deaf9866375.
> 
> That commit made mt76_dma_cleanup() disable every RX NAPI instance before
> deleting it, to silence WARNs in __netif_napi_del_locked() and
> page_pool_disable_direct_recycling() seen when unloading mt7915e with an
> MT7916.
> 
> On mt7921e and mt7925e the same instances are already disabled earlier,
> in mt7921e_unregister_device() and mt7925e_unregister_device(), which
> only afterwards call mt792x_dma_cleanup() -> mt76_dma_cleanup().  Each
> instance is therefore disabled twice, and napi_disable() is not
> idempotent: on return it leaves NAPIF_STATE_SCHED and NAPIF_STATE_NPSVC
> set, so the second call spins in usleep_range() forever, waiting for bits
> that nobody will clear.
> 
> mt7921_pci_shutdown() and mt7925_pci_shutdown() reuse the remove path, so
> this is hit on every reboot, poweroff and module unload.  It is silent:
> the stuck task keeps sleeping and rescheduling, so neither the hung task
> detector nor the lockup detectors fire, and the last line on the console
> is "systemd-shutdown[1]: Rebooting."
> [...]> Dropping the two driver-side loops instead was tried and
rejected: with
> them 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, which is a use-after-free rather than a hang [1].
> 
> Revert for now, so that reboot, poweroff and module unload work again.
> The WARNs on mt7915e are a less severe problem than an unbootable
> machine, and fixing them belongs in the drivers that delete the NAPI
> instances, where each one can pick a point that is safe for its own
> teardown order, rather than in the shared mt76_dma_cleanup().

What's the status of this? Looks like things stalled.

> Reported-by: Bert Karwatzki <spasswolf@web.de>
> Closes: https://lore.kernel.org/all/20260724151419.26014-1-spasswolf@web.de/
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221818

FWIW, I think it would be good to get this revert into 7.2 final, as
there were more reports about this:

https://bugzilla.kernel.org/show_bug.cgi?id=221848
https://bugzilla.kernel.org/show_bug.cgi?id=221862

And this is likely the same issue, too:
https://bugzilla.kernel.org/show_bug.cgi?id=221831

I've also seen multiple people mention it in a matrix channel dedicated
to Fedora's kernel.

Ciao, Thorsten

> Link: https://lore.kernel.org/all/20260730050428.GA73812@sol/ [1]
> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
> ---
> 
> Sending this because the regression is now in its second week with four
> independent reporters, and the two-part alternative (this revert plus
> napi_disable() added inside mt7915_unregister_device()) needs MT7916
> hardware that I do not have.  I deliberately left the mt7915 side out;
> Nicolas is best placed to do it, since MT7916 is what he reported
> against.
>  
> Verified on 7.2.0-rc5 with KASAN and lockdep enabled, MT7922 / mt7921e:
> before the revert 'modprobe -r mt7921e' hangs (backtrace above, taken
> with sysrq-w) and the machine never gets past "Rebooting."; after it,
> module unload and reload, reboot and poweroff all work again.
>  
> The hang was independently bisected to the same commit by Bert Karwatzki
> on MT7925 and reproduced by Devin Wittmayer on MT7927 and MT7922, and
> Eric Biggers saw it on mt7925e as well.
> 
>  drivers/net/wireless/mediatek/mt76/dma.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
> index 322041859217..f8c2fe5f2f58 100644
> --- a/drivers/net/wireless/mediatek/mt76/dma.c
> +++ b/drivers/net/wireless/mediatek/mt76/dma.c
> @@ -1189,10 +1189,7 @@ void mt76_dma_cleanup(struct mt76_dev *dev)
>  	mt76_for_each_q_rx(dev, i) {
>  		struct mt76_queue *q = &dev->q_rx[i];
>  
> -		if (!mt76_queue_is_wed_rro(q)) {
> -			napi_disable(&dev->napi[i]);
> -			netif_napi_del(&dev->napi[i]);
> -		}
> +		netif_napi_del(&dev->napi[i]);
>  		mt76_dma_rx_cleanup(dev, q);
>  
>  		page_pool_destroy(q->page_pool);

Re: [PATCH wireless] Revert "wifi: mt76: Disable napi when removing device"

[Nicolas Cavallari]

Le 04/08/2026 à 14:00, Mikhail Gavrilov a écrit :
> This reverts commit 13b7e6a96a005c656d38f3da51581deaf9866375.
> 
> That commit made mt76_dma_cleanup() disable every RX NAPI instance before
> deleting it, to silence WARNs in __netif_napi_del_locked() and
> page_pool_disable_direct_recycling() seen when unloading mt7915e with an
> MT7916.
> 
> On mt7921e and mt7925e the same instances are already disabled earlier,
> in mt7921e_unregister_device() and mt7925e_unregister_device(), which
> only afterwards call mt792x_dma_cleanup() -> mt76_dma_cleanup().  Each
> instance is therefore disabled twice, and napi_disable() is not
> idempotent: on return it leaves NAPIF_STATE_SCHED and NAPIF_STATE_NPSVC
> set, so the second call spins in usleep_range() forever, waiting for bits
> that nobody will clear.
> 
> mt7921_pci_shutdown() and mt7925_pci_shutdown() reuse the remove path, so
> this is hit on every reboot, poweroff and module unload.  It is silent:
> the stuck task keeps sleeping and rescheduling, so neither the hung task
> detector nor the lockup detectors fire, and the last line on the console
> is "systemd-shutdown[1]: Rebooting."
> 
>    task:modprobe        state:D stack:25720 pid:7954  tgid:7954
>    Call Trace:
>     <TASK>
>     __schedule+0x11b8/0x26d0
>     schedule+0xe7/0x2f0
>     schedule_hrtimeout_range_clock+0x218/0x330
>     usleep_range_state+0x133/0x1b0
>     napi_disable_locked+0x37d/0x5f0
>     napi_disable+0x43/0x80
>     mt76_dma_cleanup+0x2b4/0x860 [mt76]
>     mt7921_pci_remove+0x17f/0x350 [mt7921e]
>     pci_device_remove+0xb6/0x1e0
>     device_release_driver_internal+0x38d/0x540
>     driver_detach+0xd0/0x1b0
>     bus_remove_driver+0x127/0x2d0
>     pci_unregister_driver+0x2a/0x280
>     __do_sys_delete_module+0x36a/0x5b0
>     do_syscall_64+0x11c/0x6d0
>     entry_SYSCALL_64_after_hwframe+0x76/0x7e
>     </TASK>
> 
> Dropping the two driver-side loops instead was tried and rejected: with
> them 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, which is a use-after-free rather than a hang [1].
> 
> Revert for now, so that reboot, poweroff and module unload work again.
> The WARNs on mt7915e are a less severe problem than an unbootable
> machine, and fixing them belongs in the drivers that delete the NAPI
> instances, where each one can pick a point that is safe for its own
> teardown order, rather than in the shared mt76_dma_cleanup().
> 
> Reported-by: Bert Karwatzki <spasswolf@web.de>
> Closes: https://lore.kernel.org/all/20260724151419.26014-1-spasswolf@web.de/
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221818
> Link: https://lore.kernel.org/all/20260730050428.GA73812@sol/ [1]
> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Acked-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>

Sorry for the trouble.

For what is it worth, wifibot reports: "Series targets non-next tree, 
but doesn't contain any Fixes tags"

https://patchwork.kernel.org/project/linux-wireless/patch/20260804120004.523934-1-mikhail.v.gavrilov@gmail.com/

Fixes: 13b7e6a96a00 ("wifi: mt76: Disable napi when removing device")

> Sending this because the regression is now in its second week with four
> independent reporters, and the two-part alternative (this revert plus
> napi_disable() added inside mt7915_unregister_device()) needs MT7916
> hardware that I do not have.  I deliberately left the mt7915 side out;
> Nicolas is best placed to do it, since MT7916 is what he reported
> against.

Did that here: 
https://patchwork.kernel.org/project/linux-wireless/patch/20260810154923.32546-1-nicolas.cavallari@green-communications.fr/

Re: [PATCH wireless] Revert "wifi: mt76: Disable napi when removing device"

[Mikhail Gavrilov]

On Tue, Aug 11, 2026 at 2:11 PM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> What's the status of this? Looks like things stalled.
>

Nothing is blocked on my side - the patch is unchanged and ready to be
applied as posted.  Since it went out it has collected:

  Acked-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
  Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>

and Nicolas supplied the tag wifibot asked for, which I agree with:

  Fixes: 13b7e6a96a00 ("wifi: mt76: Disable napi when removing device")

I have not resent it, since the diff is byte for byte the same and those
trailers are in this thread for b4 to pick up.  Happy to send a v2 with
them folded in if that is easier for whoever applies it.

Nicolas has also posted the proper fix for the mt7915e WARNs that this
revert reintroduces, which depends on the revert going in first:

  https://patchwork.kernel.org/project/linux-wireless/patch/20260810154923.32546-1-nicolas.cavallari@green-communications.fr/

So the pair is complete.  Both are still sitting at "new" in patchwork:

  revert: https://patchwork.kernel.org/project/linux-wireless/patch/20260804120004.523934-1-mikhail.v.gavrilov@gmail.com/
  mt7915: https://patchwork.kernel.org/project/linux-wireless/patch/20260810154923.32546-1-nicolas.cavallari@green-communications.fr/

Felix, could you also mark my withdrawn first attempt as superseded?  It
is still at "new" too, and it must not be applied - it replaces the hang
with a use-after-free:

  https://patchwork.kernel.org/project/linux-wireless/patch/20260728002048.19351-1-mikhail.v.gavrilov@gmail.com/

-- 
Thanks,
Mikhail Gavrilov.

Re: [PATCH wireless] Revert "wifi: mt76: Disable napi when removing device"

[Nicolas Cavallari]

Le 12/08/2026 à 00:30, Mikhail Gavrilov a écrit :
> Felix, could you also mark my withdrawn first attempt as superseded?  It
> is still at "new" too, and it must not be applied - it replaces the hang
> with a use-after-free:
> 
>    https://patchwork.kernel.org/project/linux-wireless/ 
> patch/20260728002048.19351-1-mikhail.v.gavrilov@gmail.com/

Depending on the patchwork configuration, you might be able to change 
the status of your own patch if you register an account. I'm not sure if 
patchwork.kernel.org allows it, through.

Re: [PATCH wireless] Revert "wifi: mt76: Disable napi when removing device"

[Mikhail Gavrilov]

On Wed, Aug 12, 2026 at 12:13 PM Nicolas Cavallari
<nicolas.cavallari@green-communications.fr> wrote:
>
> Depending on the patchwork configuration, you might be able to change
> the status of your own patch if you register an account. I'm not sure if
> patchwork.kernel.org allows it, through.

Marked it Superseded, thanks - patchwork.kernel.org does let the
submitter change state on their own patches.

-- 
Thanks,
Mikhail Gavrilov.

Re: [PATCH wireless] Revert "wifi: mt76: Disable napi when removing device"

[Andrey Golovko]

Tested-by: Andrey Golovko <andrey@golovko.me>

Third machine, third form factor: an ASUS ProArt PX13 HN7306EAC, AMD
Strix Halo, MT7925 on PCIe (14c3:7925, mt7925e).  Kernel is v7.2-rc6
plus unrelated ASoC patches, so the regression is still there in rc6 and
rc7 - the 7.2 release is about to ship with it.

Before the revert: every poweroff and every reboot hangs after the
displays go off, machine stays powered, only holding the power button
recovers it.  'modprobe -r mt7925e' hangs the same way, with the stack
you posted:

  napi_disable_locked+0xe9/0x100
  napi_disable+0x25/0x50
  mt76_dma_cleanup+0x178/0x370 [mt76]
  mt792x_dma_cleanup+0x8f/0xb0 [mt792x_lib]
  mt7925_pci_remove+0xd7/0x1a0 [mt7925e]

After the revert: five poweroffs and one reboot in a row, all clean, and
'modprobe -r mt7925e' returns immediately.

One thing that may save the next person some time.  The hang is silent -
no watchdog fires, and here even the panic-on-stall sysctls were all set
to 1 by kdump-tools, so hung_task_panic could not catch it either.  But
device_shutdown() prints "<device>: shutdown" before each callback when
initcall_debug is on, so booting with

  initcall_debug nomodeset

names the culprit on the console: nomodeset keeps amdgpu from taking
over the framebuffer, so efifb survives to the end of the shutdown, and
the last line on the screen is

  mt7925e 0000:c2:00.0: shutdown

with no "reboot: Power down" after it.  That points at the guilty
.shutdown callback in one boot, without netconsole and without a serial
port, which on a laptop is the difference between diagnosable and not.

Andrey