From nobody Fri Oct 2 06:58:32 2026 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05A4B383C86 for ; Tue, 4 Aug 2026 12:00:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785844817; cv=none; b=QiLgHk5hnwRMQPvQM6dI+x0ufkNTA5MpprXjsnaX26abKC2y9FqUGmZsK8DoIJ6hiE1/6xT96wXLISZFJaZ4m1Xd84JKo06NN1siWve0Kf9HPtB5yrHQPY/XRBuCesu+wf7fL1sCoH2nlaHJncQya9aZYKKflkYRufya6bFuiXU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785844817; c=relaxed/simple; bh=FeySs9Jin21k5s/cqffYgru6EWdPWvaF785+FzNA150=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=QuT+hlKG4ClsjXoBRdAK2eoilnbaLkzlc1nFFUCUg4mqombJ2LyPXcBt1JDQ+ahwW9cvq4ZHePGTReTcb54qhGjIt+PRy3ZkQUMya6lOitx5hmobp4dHhZqTYomAPzly2T5atG1+E77U5PzEKz3Wl8nhKCdDoS5Xxp0LNluW+eI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=emm7b1Q/; arc=none smtp.client-ip=209.85.208.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="emm7b1Q/" Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-39c7ce122c7so38926241fa.2 for ; Tue, 04 Aug 2026 05:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785844810; x=1786449610; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=iVO/qwuBSDe5f/5RWdWMNeDvOmjgwposxFzhKBIqG+s=; b=emm7b1Q/j55xlzIBALs8oCIdKNgxd8d7rkjZNE3z0ivprO3qeFYZVXBY3lZ4Y6D6rK ulsQOtI7ecfzGDtTjM1pqGeJJu1L7bYdx8vlgzJH0ZyXKKjvc9ZnTCHgUIm5FbeAXLK3 70AcwezTlQEFDCJ9I2WZkV6X1lIN0yvM7O8Jcb9WMM3StGA94x9+q2CKRv8Gz1C8kPug MrWkP91eCh4kRCZACsARGS5LsNxsGCa5u1IqG0n0XGHX/9sKcauNIgdKXtt70cFvJ+Sz qby2pcGHzaq6O+bj3DC8NX7zgA56HOInHol3sD35paHdiJhOpl6W4uTRk5FPaVIFwfSs 9vnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785844810; x=1786449610; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=iVO/qwuBSDe5f/5RWdWMNeDvOmjgwposxFzhKBIqG+s=; b=rl8RnX7kvRMpVAIs2xH6w70cXP04+IBpQbmXGMCPzTV0wdBi6QDLO2PI/l6Sc7jg+r iJ79w3V0UR73f/QolkhTVArhwnEPRGlpBfdVW7klrMPUSyvETlOnrRNocB59IFc51J8v /cxpR1YVvzXsdRECa/LytS5OuJCqPRilc/BlguYcBCV8T8P1IIyV+bPh9ggTfINpuRZJ wNmWW4yQrFwbscgEH936Xhwhre7SBsJ68VkzSJ8lXM6dBDKzfEWeEZ4HIIMMf1W7RJq/ OvHK5uwDFpKbEWz1hGbs48rIgQXPLGXPFn9bKhDu4ov7WFVmHJMQA7aMooY7AyDeHEY7 8BkQ== X-Forwarded-Encrypted: i=1; AHgh+RpqguVg6UN8CPHMnRCfKnxAzLoSAHj3JXaqxuSQmmudD0P1cYGq74WChZEOAKu1vfbTd9ecW1Dy7jLMWIc=@vger.kernel.org X-Gm-Message-State: AOJu0YwLUWhGuUnMaRi/l9ZOdQmNP2qnUv7aIYcE2mfeJz3gDIJOHm7I jz1QtuhNP898quUA+62m4juzFZ0BVS6BpoeuSnZOUY+44dFcr7ztsSCx X-Gm-Gg: AR+sD10BF1g2E96vo43zAOchZ76ef98Yqf69D+EyzD9Cwu+rggx/trABkVkCdjQUfz4 xrMzy0mNq4GgklfAW8jhPxIMPsuUXHukn6N2tCBEh+el5JsyX9XLm8T4OC+GziqjFtBZY4zHHcC CNn5jc61ABi1uIsf8W5jECtH9qwYXjBVYohtqr6iOFrqAhvLsZAXbweb6rkzdl311XpxXvJmyif N2u6EYPOd76lmwQ7fYfUT40FvIuRmItGTHAweu6UKfuE9e21BwWd6fBmQXfoObiHF6m3bmb0xs7 1W9L9UYVRW4qYd2LKcrsewwr93HqSm+FyXTY1Vy6JV9o9N+X5BAlia5psw7+7dFeYaboqZOrrMQ WqOWDmmRKXADGmtgIkqYJMgi/mpH2w/puyc9RGpLC/RNRuGfXiqbV6HdBvU64YWIdXCeqEERNHh XQz7azlian5xLi2AzvM8aYfkWZBE4ciSngLYkDIGNwlTWOPL2P8XY9LpuQDzuEO+mdGJY1T1c= X-Received: by 2002:a05:6512:138e:b0:5b0:1dd0:f238 with SMTP id 2adb3069b0e04-5b2e4f1b067mr3121001e87.2.1785844808457; Tue, 04 Aug 2026 05:00:08 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b2e2441e66sm2620717e87.48.2026.08.04.05.00.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 05:00:07 -0700 (PDT) From: Mikhail Gavrilov To: linux-wireless@vger.kernel.org Cc: Felix Fietkau , Lorenzo Bianconi , Ryder Lee , Shayne Chen , Sean Wang , Nicolas Cavallari , Bert Karwatzki , Devin Wittmayer , Eric Biggers , Thorsten Leemhuis , regressions@lists.linux.dev, linux-kernel@vger.kernel.org, Mikhail Gavrilov Subject: [PATCH wireless] Revert "wifi: mt76: Disable napi when removing device" Date: Tue, 4 Aug 2026 17:00:04 +0500 Message-ID: <20260804120004.523934-1-mikhail.v.gavrilov@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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: __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 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 Closes: https://lore.kernel.org/all/20260724151419.26014-1-spasswolf@web.de/ Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D221818 Link: https://lore.kernel.org/all/20260730050428.GA73812@sol/ [1] Signed-off-by: Mikhail Gavrilov Acked-by: Nicolas Cavallari Tested-by: Andrey Golovko Tested-by: Devin Wittmayer --- 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. =20 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. =20 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/wireles= s/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 =3D &dev->q_rx[i]; =20 - 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); =20 page_pool_destroy(q->page_pool); --=20 2.55.0