From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935362AbcJUSkK (ORCPT ); Fri, 21 Oct 2016 14:40:10 -0400 Received: from smtp2-g21.free.fr ([212.27.42.2]:56641 "EHLO smtp2-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755719AbcJUSkA (ORCPT ); Fri, 21 Oct 2016 14:40:00 -0400 Subject: Re: Disabling an interrupt in the handler locks the system up To: Marc Zyngier , Thomas Gleixner , Jason Cooper Cc: LKML , Linux ARM , Sebastian Frias References: <580A4460.2090306@free.fr> From: Mason Message-ID: <580A60ED.3030307@free.fr> Date: Fri, 21 Oct 2016 20:39:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/10/2016 19:46, Marc Zyngier wrote: > On 21/10/16 17:37, Mason wrote: > >> On my platform, one HW block pulls the interrupt line high >> as long as it remains idle, and low when it is busy. >> >> The device tree node is: >> >> test@22222 { >> compatible = "vendor,testme"; >> interrupts = <23 IRQ_TYPE_LEVEL_HIGH>; >> }; > > I assume that this is for the sake of the discussion, and that you do > not actually intend to put together such a monstrosity. It's just missing a reg properties to be a valid node, right? >> I wrote a minimal driver which registers the irq. >> And in the interrupt handler, I disable said irq. >> >> Since the irq is IRQ_TYPE_LEVEL_HIGH, it will fire as soon as >> it is registered (because the block is idle). >> >> Here is the code I've been running, request_irq doesn't return. > > [...] > >> And here's what I get when I try to load the module: >> (I'm using the default CONFIG_RCU_CPU_STALL_TIMEOUT=21) > > [...] > >> Are we not supposed to disable the irq in the handler? > > You can. It then depends on what your interrupt controller does to > actually ensure that the interrupt is disabled. Only you can trace it on > your HW to find out. I'm using an upstream driver on v4.9-rc1 http://lxr.free-electrons.com/source/drivers/irqchip/irq-tango.c Given that the system locks up, is it possible there is a bug in the driver? Which call-back handles enabling/disabling interrupts? Regards. From mboxrd@z Thu Jan 1 00:00:00 1970 From: slash.tmp@free.fr (Mason) Date: Fri, 21 Oct 2016 20:39:41 +0200 Subject: Disabling an interrupt in the handler locks the system up In-Reply-To: References: <580A4460.2090306@free.fr> Message-ID: <580A60ED.3030307@free.fr> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 21/10/2016 19:46, Marc Zyngier wrote: > On 21/10/16 17:37, Mason wrote: > >> On my platform, one HW block pulls the interrupt line high >> as long as it remains idle, and low when it is busy. >> >> The device tree node is: >> >> test at 22222 { >> compatible = "vendor,testme"; >> interrupts = <23 IRQ_TYPE_LEVEL_HIGH>; >> }; > > I assume that this is for the sake of the discussion, and that you do > not actually intend to put together such a monstrosity. It's just missing a reg properties to be a valid node, right? >> I wrote a minimal driver which registers the irq. >> And in the interrupt handler, I disable said irq. >> >> Since the irq is IRQ_TYPE_LEVEL_HIGH, it will fire as soon as >> it is registered (because the block is idle). >> >> Here is the code I've been running, request_irq doesn't return. > > [...] > >> And here's what I get when I try to load the module: >> (I'm using the default CONFIG_RCU_CPU_STALL_TIMEOUT=21) > > [...] > >> Are we not supposed to disable the irq in the handler? > > You can. It then depends on what your interrupt controller does to > actually ensure that the interrupt is disabled. Only you can trace it on > your HW to find out. I'm using an upstream driver on v4.9-rc1 http://lxr.free-electrons.com/source/drivers/irqchip/irq-tango.c Given that the system locks up, is it possible there is a bug in the driver? Which call-back handles enabling/disabling interrupts? Regards.