On Fri, 2015-08-21 at 09:57 +0200, Johannes Berg wrote: > 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? > Come to think of it though - we might cache & delay the call so drivers actually get the updated values. 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
