iwlwifi: pcie: fix RF-Kill vs. firmware load race
authorEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Sun, 31 Jan 2016 13:02:30 +0000 (15:02 +0200)
committerEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Mon, 15 Feb 2016 11:38:25 +0000 (13:38 +0200)
commita6bd005fe92dc1cc808c4c6aa43e3b2a8272bbfa
tree72859bf12642ecdad42920a33764858655e84b7f
parent5e56276e7555b34550d51459a801ff75eca8b907
iwlwifi: pcie: fix RF-Kill vs. firmware load race

When we load the firmware, we hold trans_pcie->mutex to
avoid nested flows. We also rely on the ISR to wake up the
thread when the DMA has finished copying a chunk. During
this flow, we enable the RF-Kill interrupt.

The problem is that the RF-Kill interrupt handler can take
the mutex and bring the device down. This means that if
we load the firmware while the RF-Kill switch is enabled
(which will happen when we load the INIT firmware to read
the device's capabilities and register to mac80211), we
may get an RF-Kill interrupt immediately and the ISR will
be waiting for the mutex held by the thread that is
currently loading the firmware. At this stage, the ISR
won't be able to service the DMA's interrupt needed to
wake up the thread that load the firmware. We are in a
deadlock situation which ends when the thread that loads
the firmware fails on timeout and releases the mutex.

To fix this, take the mutex later in the flow, disable
the interrupts and synchronize_irq() to give a chance to
the RF-Kill interrupt to run and complete.
After that, mask all the interrupts besides the DMA
interrupt and proceed with firmware load. Make sure to
check that there was no RF-Kill interrupt when the
interrupts were disabled.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=111361

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
drivers/net/wireless/intel/iwlwifi/pcie/internal.h
drivers/net/wireless/intel/iwlwifi/pcie/rx.c
drivers/net/wireless/intel/iwlwifi/pcie/trans.c