No subject

bogus at bogus at
Sun Jun 2 21:10:54 PDT 2013

client* were to acquire a lock _from the application_ after having taken th=
e newly added lib_wpa_client lock, is that not correct? By having private l=
ocks inside lib_wpa_client, only code in lib_wpa_client can take said locks=
, which insure they are always taken last and thus would prevent the deadlo=
ck. More importantly, this internal lock would be released by every functio=
n taking it inside lib_wpa_client before returning (i.e. we just serialize =

I could see such a scenario happening only if lib_wpa_client can already bl=
ock forever waiting for something (in this case, with the newly added lock)=
, effectively blocking other threads every time they would call a function =
from lib_wpa_client which also takes that lock. But this would be bug even =
in mono-threaded application, as one call would simply never return ;)

> =

> A similar crash issue was fixed with this:
> =

> 7f6dd64224d22c22c8f7a497331bf5bc335e4c%5E%21/
> =

> Please check if you have the above patch.
> =

Thanks for pointing this out Vivek, but (un)fortunately we do have this pat=
ch in our tree.
One example of the crash I was referring to was in `wpa_ctrl_request()`, se=
gfaulting when dereferencing the `struct wpa_ctrl` after the `select()` sys=
call. A workaround we used is to keep the file descriptor in a local variab=
le not to dereference `ctrl` after the select, but that is just a hack...

Again, I think it will be really hard to fix all potential issues on multi-=
threaded app without adding real locking (in the callee OR caller), all oth=
er solution seem like workarounds of some kind. Waiting for your second tho=
ught on this :)

Thanks again for your time guys and have a nice day.

Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, =

92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

More information about the Hostap mailing list