On 22 May 2014 15:50, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > typo in subject. > > On Thu, 2014-05-22 at 15:28 +0200, Michal Kazior wrote: >> Even it ieee80211_beacon_get() and >> ieee80211_csa_update_counter() were to be >> guaranteed to be serialized by drivers it still >> couldn't be guaranteed to be safe on SMP systems. > > We had this debate internally as well, but I don't see where issues > should be. The only place updating the counter is > ieee80211_csa_update_counter(), and that should only be called either by > the driver, or by ieee80211_beacon_get[_tim]() [*]. If the driver wants > to have the counter update by ieee80211_beacon_get() then it must call > the function once every beacon interval, if it uses the _template() > version then it must call ieee80211_csa_update_counter() every beacon > interval, so no races seem possible. > > johannes > > [*] the driver shouldn't call ieee80211_beacon_get[_tim] and > ieee80211_csa_update_counter() in a mixed fashion anyway as that'd lead > to CSA counter bugs, and ieee80211_beacon_get_template() doesn't change > the counter I was thinking the same. The problem is without an atomic variable the code is simply oblivious to SMP. What if your beacon interrupts are spread across different CPU and your caches haven't synced yet? I suppose this is practically unlikely considering beacon intervals but still.. Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
