On Thu, 2018-02-01 at 14:33 -0800, Ben Greear wrote: > > All of RCU is suspicious Heh. 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. johannes
