From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754923Ab2L1Tqs (ORCPT ); Fri, 28 Dec 2012 14:46:48 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:55186 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754674Ab2L1TSH (ORCPT ); Fri, 28 Dec 2012 14:18:07 -0500 Message-Id: <20121228190355.829404859@decadent.org.uk> User-Agent: quilt/0.60-1 Date: Fri, 28 Dec 2012 20:05:32 +0100 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, Emmanuel Grumbach , Gregory Greenman , Johannes Berg Subject: [ 122/173] iwlwifi: dont handle masked interrupt In-Reply-To: <20121228190330.025298996@decadent.org.uk> X-SA-Exim-Connect-IP: 151.217.219.220 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.2-stable review patch. If anyone has any objections, please let me know. ------------------ From: Emmanuel Grumbach commit 25a172655f837bdb032e451f95441bb4acec51bb upstream. This can lead to a panic if the driver isn't ready to handle them. Since our interrupt line is shared, we can get an interrupt at any time (and CONFIG_DEBUG_SHIRQ checks that even when the interrupt is being freed). If the op_mode has gone away, we musn't call it. To avoid this the transport disables the interrupts when the hw is stopped and the op_mode is leaving. If there is an event that would cause an interrupt the INTA register is updated regardless of the enablement of the interrupts: even if the interrupts are disabled, the INTA will be changed, but the device won't issue an interrupt. But the ISR can be called at any time, so we ought ignore the value in the INTA otherwise we can call the op_mode after it was freed. I found this bug when the op_mode_start failed, and called iwl_trans_stop_hw(trans, true). Then I played with the RFKILL button, and removed the module. While removing the module, the IRQ is freed, and the ISR is called (CONFIG_DEBUG_SHIRQ enabled). Panic. Signed-off-by: Emmanuel Grumbach Reviewed-by: Gregory Greenman Signed-off-by: Johannes Berg [bwh: Backported to 3.2: - Adjust context - Pass bus(trans), not trans, to iwl_{read,write}32()] Signed-off-by: Ben Hutchings --- drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c +++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c @@ -1263,12 +1263,20 @@ static irqreturn_t iwl_isr(int irq, void * back-to-back ISRs and sporadic interrupts from our NIC. * If we have something to service, the tasklet will re-enable ints. * If we *don't* have something, we'll re-enable before leaving here. */ - inta_mask = iwl_read32(bus(trans), CSR_INT_MASK); /* just for debug */ + inta_mask = iwl_read32(bus(trans), CSR_INT_MASK); iwl_write32(bus(trans), CSR_INT_MASK, 0x00000000); /* Discover which interrupts are active/pending */ inta = iwl_read32(bus(trans), CSR_INT); + if (inta & (~inta_mask)) { + IWL_DEBUG_ISR(trans, + "We got a masked interrupt (0x%08x)...Ack and ignore\n", + inta & (~inta_mask)); + iwl_write32(bus(trans), CSR_INT, inta & (~inta_mask)); + inta &= inta_mask; + } + /* Ignore interrupt if there's nothing in NIC to service. * This may be due to IRQ shared with another device, * or due to sporadic interrupts thrown from our NIC. */ @@ -1349,7 +1357,7 @@ irqreturn_t iwl_isr_ict(int irq, void *d * If we have something to service, the tasklet will re-enable ints. * If we *don't* have something, we'll re-enable before leaving here. */ - inta_mask = iwl_read32(bus(trans), CSR_INT_MASK); /* just for debug */ + inta_mask = iwl_read32(bus(trans), CSR_INT_MASK); iwl_write32(bus(trans), CSR_INT_MASK, 0x00000000);