aboutsummaryrefslogtreecommitdiff
path: root/net/mac80211/tkip.h
diff options
context:
space:
mode:
authorGravatar Alexander Wetzel <alexander@wetzel-home.de> 2022-09-15 15:09:46 +0200
committerGravatar Johannes Berg <johannes.berg@intel.com> 2022-09-27 10:31:52 +0200
commit527008e5e87600a389feb8a57042c928ecca195d (patch)
tree37607409fa25fd21d784a19c896d4d0d6f1f7adb /net/mac80211/tkip.h
parentwifi: mac80211: don't start TX with fq->lock to fix deadlock (diff)
downloadlinux-527008e5e87600a389feb8a57042c928ecca195d.tar.gz
linux-527008e5e87600a389feb8a57042c928ecca195d.tar.bz2
linux-527008e5e87600a389feb8a57042c928ecca195d.zip
wifi: mac80211: ensure vif queues are operational after start
Make sure local->queue_stop_reasons and vif.txqs_stopped stay in sync. When a new vif is created the queues may end up in an inconsistent state and be inoperable: Communication not using iTXQ will work, allowing to e.g. complete the association. But the 4-way handshake will time out. The sta will not send out any skbs queued in iTXQs. All normal attempts to start the queues will fail when reaching this state. local->queue_stop_reasons will have marked all queues as operational but vif.txqs_stopped will still be set, creating an inconsistent internal state. In reality this seems to be race between the mac80211 function ieee80211_do_open() setting SDATA_STATE_RUNNING and the wake_txqs_tasklet: Depending on the driver and the timing the queues may end up to be operational or not. Cc: stable@vger.kernel.org Fixes: f856373e2f31 ("wifi: mac80211: do not wake queues on a vif that is being stopped") Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> Acked-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20220915130946.302803-1-alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'net/mac80211/tkip.h')
0 files changed, 0 insertions, 0 deletions