All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: linux-wireless@vger.kernel.org, Felix Fietkau <nbd@nbd.name>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	Ryder Lee <ryder.lee@mediatek.com>,
	Shayne Chen <shayne.chen@mediatek.com>,
	Sean Wang <sean.wang@mediatek.com>,
	Nicolas Cavallari <nicolas.cavallari@green-communications.fr>,
	Bert Karwatzki <spasswolf@web.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH mt76] wifi: mt76: mt792x: drop redundant napi_disable() in unregister path
Date: Wed, 29 Jul 2026 22:04:28 -0700	[thread overview]
Message-ID: <20260730050428.GA73812@sol> (raw)
In-Reply-To: <20260728002048.19351-1-mikhail.v.gavrilov@gmail.com>

On Tue, Jul 28, 2026 at 05:20:48AM +0500, Mikhail Gavrilov wrote:
> Commit 13b7e6a96a00 ("wifi: mt76: Disable napi when removing device")
> made mt76_dma_cleanup() disable every RX NAPI instance before deleting
> it.  mt7921e_unregister_device() and mt7925e_unregister_device() already
> disable the very same instances and only afterwards call
> mt792x_dma_cleanup() -> mt76_dma_cleanup(), so each instance is now
> disabled twice.
> 
> napi_disable() is not idempotent: on return it leaves NAPIF_STATE_SCHED
> and NAPIF_STATE_NPSVC set, so a second call without an intervening
> napi_enable() spins in usleep_range() forever, waiting for bits that
> nobody will clear:
> 
>   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>
> 
> mt7921_pci_shutdown() and mt7925_pci_shutdown() reuse the remove path,
> so the same deadlock is hit on every reboot and poweroff.  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."
> 
> Drop the driver-side loops and rely on mt76_dma_cleanup() instead.
> mt792x_dma_cleanup() stops and resets the WFDMA engine before calling
> it, so RX is already quiesced when the NAPI instances are disabled
> there.
> 
> Fixes: 13b7e6a96a00 ("wifi: mt76: Disable napi when removing device")
> Reported-by: Bert Karwatzki <spasswolf@web.de>
> Closes: https://lore.kernel.org/all/20260724151419.26014-1-spasswolf@web.de/
> Suggested-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>

While this patch fixes the shutdown hang for me too on a system using
mt7925e, Sashiko found that this patch introduces a use-after-free
because NAPI is now being disabled too late:
https://sashiko.dev/#/patchset/20260728002048.19351-1-mikhail.v.gavrilov%40gmail.com
Should 13b7e6a96a00 be reverted, then fixed in another way such as
calling napi_disable() in mt7915_unregister_device()?

- Eric

  parent reply	other threads:[~2026-07-30  5:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  0:20 [PATCH mt76] wifi: mt76: mt792x: drop redundant napi_disable() in unregister path Mikhail Gavrilov
2026-07-28 12:48 ` Bert Karwatzki
2026-07-28 17:37   ` Mikhail Gavrilov
2026-07-29  6:17 ` Devin Wittmayer
2026-07-29  6:26   ` Mikhail Gavrilov
2026-07-30  5:04 ` Eric Biggers [this message]
2026-07-30  7:07   ` Mikhail Gavrilov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260730050428.GA73812@sol \
    --to=ebiggers@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=mikhail.v.gavrilov@gmail.com \
    --cc=nbd@nbd.name \
    --cc=nicolas.cavallari@green-communications.fr \
    --cc=ryder.lee@mediatek.com \
    --cc=sean.wang@mediatek.com \
    --cc=shayne.chen@mediatek.com \
    --cc=spasswolf@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.