On Mon, Feb 27, 2012 at 04:17:41PM +0200, Kalle Valo wrote: > On 02/09/2012 09:27 AM, Vasanthakumar Thiagarajan wrote: > > From: Raja Mani <rmani@xxxxxxxxxxxxxxxx> > > > > The commit "ath6kl: Use a mutex_lock to avoid > > race in diabling and handling irq" introduces a > > state where ath6kl_sdio_irq_handler() would be waiting > > to claim the sdio function for receive indefinitely > > when things happen in the following order. > > > > ath6kl_sdio_irq_handler() > > - aquires mtx_irq > > - sdio_release_host() > > ath6kl_sdio_irq_disable() > > - sdio_claim_host() > > - sleep on mtx_irq > > ath6kl_hif_intr_bh_handler() > > - (indefinitely) wait for the sdio > > function to be released to exclusively claim > > it again for receive operation. > > > > Fix this by replacing the mtx_irq with an atomic > > variable and a wait_queue. > > > > Signed-off-by: Raja Mani <rmani@xxxxxxxxxxxxxxxx> > > Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@xxxxxxxxxxxxxxxx> > > I would really like to avoid using atomic variable if at all possible. I > was trying to think other options and what if we take in > ath6kl_sdio_irq_disable() mtx_irq before calling sdio_claim_host(). > Wouldn't that solve the deadlock? Ok, the goal is to process any pending interrupts before disabling the interrupt. Taking mutex before sdio_claim_host() would have a deadlock condition like the following sdio_claim_host() ath6kl_sdio_irq_disable() - Acquire mtx_irq ath6kl_sdio_irq_handler() - Trying to claim sdio func() - waiting on mtx_irq Vasanth -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
