lib_wpa_client: making it thread safe?

[Jouni Malinen]

On Mon, Jun 03, 2013 at 08:52:50AM +0000, Casasnovas, QuentinX wrote:
> I've come across a few crashes on Android platform where problem seems related to lib_wpa_client (or, to put it in other words, its wrong usage). As I understand, this library is not protected against concurrent access as wpa_supplicant is mono-threaded.

Well, I'm not sure I would say that to be the reason for it, but anyway,
yes, wpa_ctrl.c cannot be called from multiple threads at the same time.

> 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
operation in another thread.

> We were thinking of making the library thread safe, with a custom cflags to not create hard dependencies on other libs (e.g. pthread), instead of taking care of it in the upper level so it can benefit the most. Do you guys think that would be a good idea at all? Is it something that would potentially get merged?

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.

-- 
Jouni Malinen                                            PGP id EFC895FA