lib_wpa_client: making it thread safe?

[Casasnovas, QuentinX]

Hi Jouni, Vivek,

Thanks for your quick answers, much appreciated :)

> -----Original Message-----
> From: Vivek Natarajan [mailto:vivek.natraj at gmail.com]
> On Mon, Jun 3, 2013 at 3:09 PM, Jouni Malinen <j at w1.fi> wrote:
> >
> > > On Android platform though, the framework (which I believe is multi-
> threaded) is linked with libhardware_legacy (native library used for the
> HAL), itself linked with lib_wpa_client. During some monkey testing on our
> platform, we've seen different random crashes in lib_wpa_client, because
> no locking was used by the framework to use this interface.
> >
> > This is a known issue with Android and should be fixed (and have been
> > fixed in some branches, I'd assume) to not misuse wpa_ctrl.c
> > functions, i.e., mainly to not close the connection while there is a
> > pending

I was not aware this is a known issue, potentially already fixed, and I will look deeper in mainstream repo or in next Android version if this is the case. Thanks for the heads up :)

> > I'd concentrate on fixing the caller, not the callee.. Feel free to
> > propose changes, but I'm not sure this is really the best way of
> > addressing issues and whether the end result would really work that fine
> > if some threads are made to block on mutex (etc.) while waiting for an
> > operation to complete on another thread.

The advantage with "fixing" this directly in lib_wpa_client is that all caller would benefit from this without having to re-implement same locking over and over. Obviously if the Android framework is the only app using lib_wpa_client in a multi-threaded environment (and they have already put in place some locking), that mitigates this advantage greatly...

I am not sure to see your point with multi-threaded application potentially waiting for ever though, if you have one example in mind, would you mind describing it so we don't start implementing something that will be of no use to anyone?