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. Signed-off-by: Christian Lamparter <chunkeey@xxxxxxxxxxxxxx> --- 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. --- diff --git a/net/mac80211/main.c b/net/mac80211/main.c index a53feac..74e3529 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -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); -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
