summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorBrian Norris <briannorris@chromium.org>2017-03-29 02:59:33 +0300
committerKalle Valo <kvalo@codeaurora.org>2017-04-05 15:44:04 +0300
commit755b37c93a069ff0882411630a06e90b3193d092 (patch)
tree83d34d390fe620f70cb6ead4971c4486913da750 /tools/perf/scripts/python
parentce8fad9a1f09009ec3918a99685d9e3176f50ce3 (diff)
downloadlinux-755b37c93a069ff0882411630a06e90b3193d092.tar.xz
mwifiex: catch mwifiex_fw_dpc() errors properly in reset
When resetting the device, we take a synchronous firmware-loading code path, which borrows a lot from the asynchronous path used at probe time. We don't catch errors correctly though, which means that in the PCIe driver, we may try to dereference the 'adapter' struct after mwifiex_fw_dpc() has freed it. See this (erronous) print in mwifiex_pcie_reset_notify(): mwifiex_dbg(adapter, INFO, "%s, successful\n", __func__); Let's instead refactor the synchronous (or "!req_fw_nowait") path so that we propagate errors and handle them properly. This fixes a use-after-free issue in the PCIe driver, as well as a misleading debug message ("successful"). It looks like the SDIO driver doesn't have these problems, since it doesn't do anything after mwifiex_reinit_sw(). Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions