<div dir="ltr"><div><div>All right.<br></div>Gonna test your suggestion and check if regression is ok. Should I send this patch again or are you gonna do that?<br><br></div>Regards.<br></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Wed, Mar 19, 2014 at 8:38 AM, Otcheretianski, Andrei <span dir="ltr"><<a href="mailto:andrei.otcheretianski@intel.com" target="_blank">andrei.otcheretianski@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The only place where wpa_s->radio is set to NULL is in radio_remove_interface.. Since radio_remove_works should remove all the works (including started) and it is called right before setting wpa_s->radio = NULL, I can't see any scenario where work->wpa_s->radio == NULL<br>
<br>
> From: Eduardo Abinader [mailto:<a href="mailto:eduardo.abinader@openbossa.org">eduardo.abinader@openbossa.org</a>]<br>
> Sent: Wednesday, March 19, 2014 13:25<br>
> To: Otcheretianski, Andrei<br>
> Subject: Re: [PATCH 1/2] Fix radio remove works<br>
<div class="HOEnZb"><div class="h5">><br>
> Actually, I did cogitate a very similar solution, but I was wondering if there was some deferred radio work still being removed or cleaned, so that's why I decided to implement in radio_remove_works.<br>
><br>
> The work->wpa_s is just a sanity check for work->wpa_s->radio, actually. Just to be safer.<br>
><br>
><br>
> Regards.<br>
><br>
><br>
><br>
> On Wed, Mar 19, 2014 at 4:21 AM, Otcheretianski, Andrei <<a href="mailto:andrei.otcheretianski@intel.com">andrei.otcheretianski@intel.com</a>> wrote:<br>
><br>
><br>
> Hi,<br>
> Checking work->wpa_s doesn't make sense, since it is set in radio_add_work and never unset.<br>
> Anyway I think the fix should be more like this:<br>
><br>
> @@ -3259,6 +3259,7 @@ static void radio_remove_interface(struct wpa_supplicant *wpa_s)<br>
> wpa_s->ifname, radio->name);<br>
> dl_list_del(&wpa_s->radio_list);<br>
> if (!dl_list_empty(&radio->ifaces)) {<br>
> + radio_remove_works(wpa_s, NULL, 0);<br>
> wpa_s->radio = NULL;<br>
> return; /* Interfaces remain for this radio */<br>
> }<br>
><br>
> Regards,<br>
> Andrei<br>
><br>
><br>
><br>
> > -----Original Message-----<br>
> > From: <a href="mailto:hostap-bounces@lists.shmoo.com">hostap-bounces@lists.shmoo.com</a> [mailto:<a href="mailto:hostap-">hostap-</a><br>
> > <a href="mailto:bounces@lists.shmoo.com">bounces@lists.shmoo.com</a>] On Behalf Of Eduardo Abinader<br>
> > Sent: Tuesday, March 18, 2014 15:51<br>
> > To: <a href="mailto:hostap@lists.shmoo.com">hostap@lists.shmoo.com</a><br>
> > Subject: [PATCH 1/2] Fix radio remove works<br>
> ><br>
> > When radio has been previously removed and pending radio works related<br>
> > to an excluded interface remains, new works are not capable of being<br>
> > executed. That occurs when a potential P2P client fails to negotiate group<br>
> > formation. For some reason, the P2P device is no more capable of issuing<br>
> > radio works. Those checks prevent this situation, by allowing removal of<br>
> > previous radio works.<br>
> ><br>
> > Signed-off-by: Eduardo Abinader <<a href="mailto:eduardo.abinader@openbossa.org">eduardo.abinader@openbossa.org</a>><br>
> > ---<br>
> > wpa_supplicant/wpa_supplicant.c | 3 ++-<br>
> > 1 file changed, 2 insertions(+), 1 deletion(-)<br>
> ><br>
> > diff --git a/wpa_supplicant/wpa_supplicant.c<br>
> > b/wpa_supplicant/wpa_supplicant.c index 499dcb3..c74ac20 100644<br>
> > --- a/wpa_supplicant/wpa_supplicant.c<br>
> > +++ b/wpa_supplicant/wpa_supplicant.c<br>
> > @@ -3176,7 +3176,8 @@ void radio_remove_works(struct wpa_supplicant<br>
> > *wpa_s,<br>
> ><br>
> > dl_list_for_each_safe(work, tmp, &radio->work, struct<br>
> > wpa_radio_work,<br>
> > list) {<br>
> > - if (type && os_strcmp(type, work->type) != 0)<br>
> > + if (work->wpa_s && work->wpa_s->radio && type &&<br>
> > + os_strcmp(type, work->type) != 0)<br>
> > continue;<br>
> ><br>
> > /* skip other ifaces' works */<br>
> > --<br>
> > 1.8.3.2<br>
> ><br>
</div></div><div class="HOEnZb"><div class="h5">---------------------------------------------------------------------<br>
A member of the Intel Corporation group of companies<br>
<br>
This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<br>
<br>
</div></div></blockquote></div><br></div>