On Thu, 2015-08-20 at 17:39 -0400, Marty Faltesek wrote: > > I believe the following race occurs: > > 1. mac80211 is processing a new station that just joined. > 2. Before it's completed initializing the station, we take an > interrupt, > with a packet from the STA. > 3. That interrupt is a management frame from the station which causes > rate_control_rate_update to be called, which calls back into the > ath10k > with the not-fully initialized station. I'm a bit confused by the stack trace - is this IBSS and the stack trace is just bad? I don't really see how we get from sta_ps_transition to sta_rc_update? > 4. It reaches ath10k_sta_rc_update before the interrupted thread had > reached ath10k_sta_state() > Therefore it has not yet initialized its workqueue. Still NULL. > 5. When this NULL workqueue gets passed to queue_work, it passes > the first check that its not in use because of the NULL struct, > but fails the > next check in __queue_work because a NULL structure makes the test > for an empty list fail. > > > Proposed patch is to not add the new station in the hash until after > the > driver initializes it. But I'm not clear what implications this has. > Could this > cause other problems? > I think the issue Michał pointed out is valid - but we can probably check sta->uploaded in the relevant places? johannes -- 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
