[PATCH 06/10] wpa_supplicant: Handle race condition in sched_scan stop

[Jouni Malinen]

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
needed here?

-- 
Jouni Malinen                                            PGP id EFC895FA