wifi: mt76: mt7925: post-#72 teardown fix follow-up - #74
Closed
Ashcal9669 wants to merge 1 commit into
Closed
Conversation
mt7925e_unregister_device() had two independent bugs in its teardown
ordering, both in the RX NAPI/token-idr handling around
mt7925_tx_token_put(), plus a separate tasklet lifetime gap in
mt7925_pci_remove().
1. It called napi_disable() directly on every RX queue, then a few
lines later mt792x_dma_cleanup() -> mt76_dma_cleanup() called
napi_disable() on the same NAPI instances again, with no
napi_enable() in between. napi_disable() leaves NAPI_STATE_SCHED
set until a matching napi_enable(); a second, unpaired call on an
already-disabled NAPI has nothing left to wait for that can ever
clear that bit, so it hangs unconditionally.
This is the same bug independently found and reported upstream by
Mikhail Gavrilov ("wifi: mt76: mt792x: drop redundant napi_disable()
in unregister path", 13b7e6a96a00) and by Devin Wittmayer
(morrownr#70 review). Root cause: 4ab8f2122dcb added this same
napi_disable() to mt76_dma_cleanup(), was reverted by f5f14a017454
("Needs to be fixed to avoid regression on mt762x"), then re-added
by 332bbe9b2784 without removing the driver-side napi_disable()
loops in mt7921/pci.c and mt7925/pci.c that predate it.
2. Once the redundant loop above was deleted without care, NAPI was no
longer quiesced before mt7925_tx_token_put()'s idr_destroy(). A
still in-flight RX NAPI poll can reach PKT_TYPE_TXRX_NOTIFY ->
mt7925_mac_tx_free() -> mt76_token_release() -> idr_remove() on the
same idr concurrently with that idr_destroy() -- a real
use-after-free, not a redundant check. Confirmed independently
twice: Sashiko (via Eric Biggers) against Mikhail's patch upstream,
and Sashiko/Lucid-Duck against an earlier version of this fix
(morrownr#70). tasklet_disable() alone is not sufficient: it
only blocks *future* napi_schedule() calls, it does not wait out a
poll already running. napi_disable() does wait for it, closing the
race.
Fixed here by restoring a single napi_disable() loop in
mt7925e_unregister_device(), positioned before mt7925_tx_token_put()
as in bug 2, kept disabled afterward rather than re-enabled: upstream
PR morrownr#72 (following Mikhail's own proposed v2, reverting
332bbe9b2784) removed mt76_dma_cleanup()'s own napi_disable() entirely,
so this driver-side call is now the only one and there is nothing left
to double-disable. Re-enabling here would leave RX NAPI on going into
mt792x_dma_cleanup()'s netif_napi_del()/page_pool_destroy(), which is
exactly what those warn about if NAPI is still active. MT76_REMOVED
early-exits were added to mt792x_irq_tasklet(), mt792x_poll_tx() and
mt792x_poll_rx() (mt792x_dma.c) matching the pattern already used by
the non-PCI bus types in this driver family, so nothing can turn NAPI
back on in this window regardless.
Also: mt792x_dma_cleanup()/mt792x_wfsys_reset() do raw WFDMA/WFSYS
register I/O and need driver ownership of the chip.
mt76_unregister_device() above runs mac80211 vif teardown, which can
queue pm->ps_work and hand ownership back to firmware before
cancel_delayed_work_sync(&pm->ps_work) catches it. A new
__mt792x_mcu_drv_pmctrl(dev) call was added right before
mt76_unregister_device(), since that teardown itself needs ownership
too; the existing call right before mt792x_dma_cleanup() is unchanged
from before this fix and guarantees ownership is fresh again at the
point it's actually needed, independent of what ps_work did in
between.
Separately: mt7925_pci_remove() never called tasklet_kill() on
irq_tasklet before mt76_free_device(); the only existing
tasklet_kill() in this file is in the suspend path. tasklet_disable()
alone does not remove an already-scheduled instance from the pending
list, so a tasklet still pending when the containing struct is freed
is a use-after-free waiting to happen. Independently flagged upstream
by Mikhail Gavrilov in the same thread as bug 1. Added
tasklet_kill(&dev->mt76.irq_tasklet) in mt7925_pci_remove(), after
devm_free_irq() and before mt76_free_device().
That fix's first version also added a tasklet_disable() in
mt7925e_unregister_device(), reasoning it would help close bug 2 the
same way napi_disable() does. It doesn't, and it actively conflicts
with tasklet_kill(): tasklet_kill() waits for TASKLET_STATE_SCHED to
clear, but a *disabled* tasklet that gets scheduled never clears that
bit (the softirq handler sees it's disabled and just re-queues it), so
tasklet_kill() on a disabled-and-pending tasklet spins instead of
returning (morrownr#71 review, Lucid-Duck). mt792x_irq_handler()
already checks MT76_REMOVED before calling tasklet_schedule() at all,
so no new scheduling can happen once it's set (before this function
runs); mt792x_irq_tasklet()'s own MT76_REMOVED guard makes the tasklet
body itself inert if it does run once more from an IRQ that raced the
flag. Between those two, tasklet_disable() here was not preventing
anything tasklet_kill() doesn't already handle correctly on its own,
so it was dropped.
Fixes: 332bbe9b2784 ("wifi: mt76: fix connac2/3 DMA queue cleanup")
Link: morrownr#70
Link: morrownr#71
Link: morrownr#72
Link: https://lore.kernel.org/all/CABXGCsO07SExb+Z0PeN6MZ1fKC24Tvn3ehSyeQc-3qFC7jM7dQ@mail.gmail.com/
Verified: all tests/mt7927/*.sh source contracts covering this
function pass, clean build against 7.2.0-rc1-mt7927-monitor-v3, 4
consecutive real modprobe/modprobe -r cycles on physical MT7927
hardware idle, and 5 more with active RX traffic in flight during each
unload, zero hangs and zero dmesg warnings across all of them.
Not in this change: mt7921e_unregister_device() (mt7921/pci.c) has the
same missing tasklet_kill() gap in mt7921_pci_remove(), and
mt7921_pci_remove() sets MT76_REMOVED *after* calling unregister
(mt7925_pci_remove() sets it before), so the MT76_REMOVED guards added
here don't protect mt7921e either. Left out of scope for this PR;
flagging so it isn't mistaken for an oversight.
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #71.
After #72 reverted the shared second
napi_disable(), this branch carries the current MT7925 teardown fix candidate on a restored PR #73 so review can happen against the right thread.This version keeps the pieces that still matter after #72:
MT76_REMOVEDearly exits inmt792x_irq_tasklet(),mt792x_poll_tx(), andmt792x_poll_rx()mt7925_tx_token_put()soidr_destroy()does not race an in-flightmt76_token_release()pathtasklet_kill(&dev->mt76.irq_tasklet)inmt7925_pci_remove()to close the remove-time tasklet lifetime gap__mt792x_mcu_drv_pmctrl(dev)needed somt76_unregister_device()teardown runs with driver ownershipReference review context:
Current goal for this PR: review the actual post-#72 MT7925 fix in its own thread without changing the already-open #71 history.