mac80211: cancel restart_work in ieee80211_unregister_hw
PATCH 1/1 mac80211: cancel restart_work in ieee80211_unregister_hw
Unlike most other workqueue-tasks, the restart_work is not scheduled onto mac80211's private per-interface workqueue, but onto one of the system-wide workqueues.
Therefore the mac80211-stack has to cancel any pending restarts, before destroying the shared device context and handing back the memory. Otherwise - under very unlucky circumstances - there could be a stale work- item left, because some other kernel component might have delayed the execution of ieee80211_restart_work for too long.
---
Sure, normally a device doesn't simply disappear, but you know: restarts might take some time (fw upload, phy/mac/crypto reinit, etc.) to finish and some impatient user might want to speed things up by _simply_ replugging the USB device...
But don't ask me what this "elusive" kernel component could be, I stumbled upon this theoretical bug, while reviewing code in order to prevent crashes from a driver, which relies on a fully functional restart support.
---
net/mac80211/main.c +1 -0
@@ -807,6 +807,7 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)rtnl_unlock (); +cancel_work_sync (&local->restart_work);cancel_work_sync (&local->reconfig_filter);ieee80211_clear_tx_pending (local);
Quoted 12 lines · Christian Lamparter
Unlike most other workqueue-tasks, the
restart_workis not scheduled onto mac80211's private per-interface workqueue, but onto one of the system-wide workqueues.Therefore the mac80211-stack has to cancel any pending restarts, before destroying the shared device context and handing back the memory. Otherwise - under very unlucky circumstances - there could be a stale work- item left, because some other kernel component might have delayed the execution of
ieee80211_restart_workfor too long.
Quoted 1 line
Signed-off-by Christian Lamparter <[email protected]>
Is this a stable fix?
Luis