[PATCH 06/10] wpa_supplicant: Handle race condition in sched_scan stop
j at w1.fi
Sat Oct 29 09:37:05 PDT 2016
On Thu, Oct 27, 2016 at 03:18:28PM +0300, Andrei Otcheretianski wrote:
> In case that stop sched command is sent after the completion of
> scheduled scan and before the processing of the
> EVENT_SCHED_SCAN_STOPPED event, stopping the scheduled scan would
> fail, in such a case do not set the sched_scan_stop_req flag.
So this patch is for wpas_stop_pno().. What about
wpa_supplicant_cancel_sched_scan() which is also calling
wpa_supplicant_stop_sched_scan() and setting wpa_s->sched_scan_stop_req
= 1 regardless of what wpa_supplicant_stop_sched_scan() returns?
> diff --git a/wpa_supplicant/scan.c b/wpa_supplicant/scan.c
> @@ -2550,7 +2550,14 @@ int wpas_stop_pno(struct wpa_supplicant *wpa_s)
> return 0;
> ret = wpa_supplicant_stop_sched_scan(wpa_s);
> - wpa_s->sched_scan_stop_req = 1;
> + /* In case that stop sched command is sent after the completion of
> + * sched scan and before processing the EVENT_SCHED_SCAN_STOPPED event,
> + * stopping the scheduled scan would fail.
> + * In such a case do not set the flag
> + */
> + if (!ret)
> + wpa_s->sched_scan_stop_req = 1;
> wpa_s->pno = 0;
So this is already protected with !wpa_s->pno above this context. I'm
not sure I fully understood the sequence in which this could be hit.
Would you happen to have a debug log showing a case where this change is
Jouni Malinen PGP id EFC895FA
More information about the Hostap