summaryrefslogtreecommitdiff
path: root/drivers/ata
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2017-05-27 00:27:25 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-11-10 07:42:47 -0800
commitfd500b357b81df3b0827fe1e6a7d0debe6506494 (patch)
treed4128f75ff5a442892b26078494c088d1811cae0 /drivers/ata
parent942630bb4c9e7a69b08c939de470e174f8ce8a82 (diff)
mac80211: fix TX aggregation start/stop callback race
[ Upstream commit 7a7c0a6438b8e7636d5a22e572892cc234f68297 ] When starting or stopping an aggregation session, one of the steps is that the driver calls back to mac80211 that the start/stop can proceed. This is handled by queueing up a fake SKB and processing it from the normal iface/sdata work. Since this isn't flushed when disassociating, the following race is possible: * associate * start aggregation session * driver callback * disassociate * associate again to the same AP * callback processing runs, leading to a WARN_ON() that the TID hadn't requested aggregation If the second association isn't to the same AP, there would only be a message printed ("Could not find station: <addr>"), but the same race could happen. Fix this by not going the whole detour with a fake SKB etc. but simply looking up the aggregation session in the driver callback, marking it with a START_CB/STOP_CB bit and then scheduling the regular aggregation work that will now process these bits as well. This also simplifies the code and gets rid of the whole problem with allocation failures of said skb, which could have left the session in limbo. Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'drivers/ata')
0 files changed, 0 insertions, 0 deletions