-
Sujith Manoharan authored
ath10k_tx_wep_key_work() acquires conf_mutex, so cancelling it when conf_mutex is already taken in ath10k_remove_interface() is incorrect, so move it outside the lock. Snippet from the lockdep report: kernel: ====================================================== kernel: [ INFO: possible circular locking dependency detected ] kernel: 3.18.0-rc5-wl-debug #34 Tainted: G O kernel: ------------------------------------------------------- kernel: hostapd/451 is trying to acquire lock: kernel: ((&arvif->wep_key_work)){+.+...}, at: [<ffffffff810872d5>] flush_work+0x5/0x290 kernel: but task is already holding lock: kernel: (&ar->conf_mutex){+.+.+.}, at: [<ffffffffa0b99f00>] ath10k_remove_interface+0x40/0x290 [ath10k_core] kernel: which lock already depends on the new lock. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
5d011f5c