GitLab

There were crashes reported in this code, and the timer_shutdown()
warning in one of the previous patches indicates that the timeout
timer for the AP response (addba_resp_timer) is still armed while
we're stopping the aggregation session.

After a very long deliberation of the code, so far the only way I
could find that might cause this would be the following sequence:
 - session start requested
 - session start indicated to driver, but driver returns
   IEEE80211_AMPDU_TX_START_DELAY_ADDBA
 - session stop requested, sets HT_AGG_STATE_WANT_STOP
 - session stop worker runs ___ieee80211_stop_tx_ba_session(),
   sets HT_AGG_STATE_STOPPING

From here on, the order doesn't matter exactly, but:

 1. driver calls ieee80211_start_tx_ba_cb_irqsafe(),
    setting HT_AGG_STATE_START_CB
 2. driver calls ieee80211_stop_tx_ba_cb_irqsafe(),
    setting HT_AGG_STATE_STOP_CB
 3. the worker will run ieee80211_start_tx_ba_cb() for
    HT_AGG_STATE_START_CB
 4. the worker will run ieee80211_stop_tx_ba_cb() for
    HT_AGG_STATE_STOP_CB

(the order could also be 1./3./2./4.)

This will cause ieee80211_start_tx_ba_cb() to send out the AddBA
request frame to the AP and arm the timer, but we're already in
the middle of stopping and so the ieee80211_stop_tx_ba_cb() will
no longer assume it needs to stop anything.

Prevent this by checking for WANT_STOP/STOPPING in the start CB,
and warn if we're sending a frame on a stopping session.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230618214436.e5b52777462a.I0b2ed6658e81804279f5d7c9c1918cb1f6626bf2@changeid

Signed-off-by: Johannes Berg <johannes.berg@intel.com>