From patchwork Tue Feb 7 12:52:16 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Lothar_Wa=C3=9Fmann?= X-Patchwork-Id: 139918 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from merlin.infradead.org (unknown [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id DA5D51007D3 for ; Tue, 7 Feb 2012 23:54:58 +1100 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1RukX4-0000T0-QQ; Tue, 07 Feb 2012 12:52:26 +0000 Received: from mail.karo-electronics.de ([81.173.242.67]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1RukWz-0000Sm-Td for linux-arm-kernel@lists.infradead.org; Tue, 07 Feb 2012 12:52:24 +0000 Message-ID: <20273.7808.730105.307619@ipc1.ka-ro> Date: Tue, 7 Feb 2012 13:52:16 +0100 From: =?utf-8?Q?Lothar_Wa=C3=9Fmann?= To: Yong Zhang Mime-Version: 1.0 Subject: Re: [BUG] genirq: Race condition in ONESHOT IRQ handler disabling IRQ forever In-Reply-To: <20120207123455.GA2452@zhy> References: <20271.35831.227679.177366@ipc1.ka-ro> <20120207090305.GB32736@zhy> <20272.63074.235023.783459@ipc1.ka-ro> <20120207123455.GA2452@zhy> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org Hi, Yong Zhang writes: > On Tue, Feb 07, 2012 at 11:01:06AM +0100, Lothar Waßmann wrote: > > Hi, > > > > > On Mon, Feb 06, 2012 at 09:14:47AM +0100, Lothar Waßmann wrote: > > > > Hi, > > > > > > > > I already sent this to on Feb. 1, 2012 > > > > but did not get any response there. So resending to a wider audience > > > > with improved subject line: > > > > > > > > there is a race condition in the threaded IRQ handler code for oneshot > > > > interrupts that may lead to disabling an IRQ indefinitely. IRQs are > > > > masked before calling the hard-irq handler and are unmasked only after > > > > the soft-irq handler has been run. Thus if the hard-irq handler > > > > returns IRQ_HANDLED instead of IRQ_WAKE_THREAD, meaning the soft-irq > > > > will not be called, the interrupt will remain masked forever. > > > > > > > > This can happen due to a short pulse on the interrupt line, that > > > > triggers the interrupt logic, but goes undetected by the hard-irq > > > > handler. The problem can be reproduced with the TSC2007 touch > > > > controller driver that uses ONESHOT interrupts. > > > > > > Isn't it the responsibility of the driver (say TSC2007)? > > > > > > In this case, TSC2007 should return IRQ_WAKE_THREAD IMHO. > > > > > That would mean it had to return IRQ_WAKE_THREAD unconditionally > > making the return code useless. > > And it would cause an extra useless loop through the softirq > > handler. > > Yeah, it's the default behavior when we introduce 'theadirqs', > and it's safe. > So, the correct solution would be to remove the check for IRQ_WAKE_THREAD in handle_irq_event_percpu() and always invoke the softirq handler? Note that this problem is not specific to the TSC2007 driver, but may occur with any hardware. Or maybe do the unmasking in handle_irq_event() as proposed by Lars-Peter Clausen in <4F2FAE93.5020205@metafoo.de>? Like that: Lothar Waßmann diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c index f7c543a..fbf68c7 100644 --- a/kernel/irq/chip.c +++ b/kernel/irq/chip.c @@ -343,6 +343,8 @@ EXPORT_SYMBOL_GPL(handle_simple_irq); void handle_level_irq(unsigned int irq, struct irq_desc *desc) { + int ret; + raw_spin_lock(&desc->lock); mask_ack_irq(desc); @@ -360,10 +362,12 @@ handle_level_irq(unsigned int irq, struct irq_desc *desc) if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) goto out_unlock; - handle_irq_event(desc); + ret = handle_irq_event(desc); - if (!irqd_irq_disabled(&desc->irq_data) && !(desc->istate & IRQS_ONESHOT)) + if (!irqd_irq_disabled(&desc->irq_data) && + (!(desc->istate & IRQS_ONESHOT) || ret != IRQ_WAKE_THREAD)) unmask_irq(desc); + out_unlock: raw_spin_unlock(&desc->lock); }