On Thursday 05 March 2015 16:37:12 Johannes Berg wrote:
> From: Johannes Berg <[email protected]>
>
> Both minstrel (reported by Sven Eckelmann) and the iwlwifi rate
> control aren't properly taking concurrency into account. It's
> likely that the same is true for other rate control algorithms.
>
> In the case of minstrel this manifests itself in crashes when an
> update and other data access are run concurrently, for example
> when the stations change bandwidth or similar. In iwlwifi, this
> can cause firmware crashes.
>
> Since fixing all rate control algorithms will be very difficult,
> just provide locking for invocations. This protects the internal
> data structures the algorithms maintain.
>
> I've manipulated hostapd to test this, by having it change its
> advertised bandwidth roughly ever 150ms. At the same time, I'm
> running a flood ping between the client and the AP, which causes
> this race of update vs. get_rate/status to easily happen on the
> client. With this change, the system survives this test.
>
> Reported-by: Sven Eckelmann <[email protected]>
> Signed-off-by: Johannes Berg <[email protected]>
Thanks a lot for the patch. This is mostly what I had in mind when asking for
the correct lock.
I will ask if it is possible to test this patch in an affected network. But I
am quite sure that this will not be possible before next week. And your test
already sounds quite nice.
Kind regards,
Sven
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
