On 02/01/2018 02:47 PM, Johannes Berg wrote:
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.
It looks like the code in ath9k has not been changed in that area for
some time.
Would adding rcu_read_lock in drv_sta_state() be a possibility?
Thanks,
Ben
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
