On Thu, 2018-02-01 at 23:40 +0100, Johannes Berg wrote: > > The code does a plain rcu_dereference(), no locking other than > rcu_read_lock() involved. > > On second thought though, I'm not convinced that your modifications > caused the problem. > > Given your call stack, we'd expect rcu_read_lock() somewhere around > ath_tid_dequeue (or its caller(s)), since ieee80211_tx_dequeue clearly > requires it. > > Normally, ieee80211_tx_dequeue() is called from various places that > probably come from mac80211 and already hold the rcu_read_lock(), e.g. > the wake_tx_queue op. > > In this case, you're coming from drv_sta_state, so not sure why the > driver thinks it's OK to call the dequeue there. Just to clarify - it could just be that in the "normal" case, when a station dies, there's nothing on the queues - so the dequeue just doesn't do anything and never goes into the code path where the rcu_dereference() is, hence it might be a bug in mainline that just never triggers in ordinary scenarios. johannes
