summaryrefslogtreecommitdiff
path: root/block/partition-generic.c
diff options
context:
space:
mode:
authorBrian Norris <briannorris@chromium.org>2016-11-18 19:30:26 +0530
committerKalle Valo <kvalo@codeaurora.org>2016-11-19 09:18:48 +0200
commit4a79aa17d53ea8d5fa4acdaed487a786a185936a (patch)
tree17fac95b50f4108fc9edad96275494b534f1cd42 /block/partition-generic.c
parent6712076883ca49532b4e15216fb69cde69a5a919 (diff)
mwifiex: resolve races between async FW init (failure) and device removal
It's possible for the FW init sequence to fail, which will trigger a device cleanup sequence in mwifiex_fw_dpc(). This sequence can race with device suspend() or remove() (e.g., reboot or unbind), and can trigger use-after-free issues. Currently, this driver attempts (poorly) to synchronize remove() using a semaphore, but it doesn't protect some of the critical sections properly. Particularly, we grab a pointer to the adapter struct (card->adapter) without checking if it's being freed or not. We later do a NULL check on the adapter, but that doesn't work if the adapter was freed. Also note that the PCIe interface driver doesn't ever set card->adapter to NULL, so even if we get the synchronization right, we still might try to redo the cleanup in ->remove(), even if the FW init failure sequence already did it. This patch replaces the static semaphore with a per-device completion struct, and uses that completion to synchronize the remove() thread with the mwifiex_fw_dpc(). A future patch will utilize this completion to synchronize the suspend() thread as well. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Diffstat (limited to 'block/partition-generic.c')
0 files changed, 0 insertions, 0 deletions