summaryrefslogtreecommitdiff
path: root/net/qrtr/ns.c
diff options
context:
space:
mode:
authorAlexander Wetzel <alexander@wetzel-home.de>2022-09-15 14:41:20 +0200
committerJohannes Berg <johannes.berg@intel.com>2022-09-27 10:29:04 +0200
commitb7ce33df1ce2b6631234233c5367bcfe9c67fbe9 (patch)
tree3aaea8c0553c5f810cb2fec3a953fd0a2d9b3121 /net/qrtr/ns.c
parent64e966d1e84b29c9fa916cfeaabbf4013703942e (diff)
wifi: mac80211: don't start TX with fq->lock to fix deadlock
ieee80211_txq_purge() calls fq_tin_reset() and ieee80211_purge_tx_queue(); Both are then calling ieee80211_free_txskb(). Which can decide to TX the skb again. There are at least two ways to get a deadlock: 1) When we have a TDLS teardown packet queued in either tin or frags ieee80211_tdls_td_tx_handle() will call ieee80211_subif_start_xmit() while we still hold fq->lock. ieee80211_txq_enqueue() will thus deadlock. 2) A variant of the above happens if aggregation is up and running: In that case ieee80211_iface_work() will deadlock with the original task: The original tasks already holds fq->lock and tries to get sta->lock after kicking off ieee80211_iface_work(). But the worker can get sta->lock prior to the original task and will then spin for fq->lock. Avoid these deadlocks by not sending out any skbs when called via ieee80211_free_txskb(). Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> Link: https://lore.kernel.org/r/20220915124120.301918-1-alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'net/qrtr/ns.c')
0 files changed, 0 insertions, 0 deletions