[PATCH] Fix scanning state when sched_scan is stopped explicitly

[Dmitry Shmidt]

On Mon, Mar 9, 2015 at 12:56 PM, Johannes Berg
<johannes at sipsolutions.net> wrote:
> On Mon, 2015-03-09 at 12:46 -0700, Dmitry Shmidt wrote:
>> >> immediately. However, it takes time for event to propagate back:
>> >>   nl80211_stop_sched_scan() -> __cfg80211_stop_sched_scan() ->
>> >>   nl80211_send_sched_scan(rdev, dev, NL80211_CMD_SCHED_SCAN_STOPPED);
>> >> so when wpa_supplciant gets NL80211_CMD_SCHED_SCAN_STOPPED
>> >> that will be translated to EVENT_SCHED_SCAN_STOPPED to clear
>> >>   wpa_s->scanning
>> >> it will be too late
>> >
>> > Which driver are you using? ISTR fixing a number of issues in this area.
>>
>> We are using Broadcom and Qualcomm drivers. However, I am not sure that
>> driver is relevant here - all the calls I described above are done by kernel
>> wireless stack and wpa_supplicant.
>
> Right but I think we fixed the stack to report the event back before the
> stop_sched_scan() call can return? But my memory of this is very vague,
> I might very well be mistaken and would have to check the code.

If you can hint me what this change was about, I'll try to find it.
Meanwhile the only change I see between 3.19 and 3.4 in
__cfg80211_stop_sched_scan() is to use rtnl_lock instead of sched_scan_mtx.
Other than that the logic is the same - send stop command to the driver and send
 NL80211_CMD_SCHED_SCAN_STOPPED back to user space.
And I see (I didn't try 3.19) that it will come "too late".

>
> johannes
>