diff options
| author | Jouni Malinen <j@w1.fi> | 2013-09-30 12:36:05 +0300 |
|---|---|---|
| committer | Johannes Berg <johannes.berg@intel.com> | 2013-09-30 12:36:56 +0200 |
| commit | 22c4ceed0184318ec5a6182c6d75d398452c2e39 (patch) | |
| tree | 061bbe36e029fa9b6ee40ebd5b4f129bfbd92bfb | |
| parent | 0c5b93290b2f3c7a376567c03ae8d385b0e99851 (diff) | |
| download | linux-22c4ceed0184318ec5a6182c6d75d398452c2e39.tar.gz linux-22c4ceed0184318ec5a6182c6d75d398452c2e39.tar.bz2 linux-22c4ceed0184318ec5a6182c6d75d398452c2e39.zip | |
mac80211: Run deferred scan if last roc_list item is not started
mac80211 scan processing could get stuck if roc work for pending, but
not started when a scan request was deferred due to such roc item.
Normally the deferred scan would be started from
ieee80211_start_next_roc(), but ieee80211_sw_roc_work() calls that only
if the finished ROC was started. Fix this by calling
ieee80211_run_deferred_scan() in the case the last ROC was not actually
started.
This issue was hit relatively easily in P2P find operations where Listen
state (remain-on-channel) and Search state (scan) are repeated in a
loop.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| -rw-r--r-- | net/mac80211/offchannel.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c index acd1f71adc03..0c2a29484c07 100644 --- a/net/mac80211/offchannel.c +++ b/net/mac80211/offchannel.c @@ -394,6 +394,8 @@ void ieee80211_sw_roc_work(struct work_struct *work) if (started) ieee80211_start_next_roc(local); + else if (list_empty(&local->roc_list)) + ieee80211_run_deferred_scan(local); } out_unlock: |