Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758709AbXHVNeV (ORCPT ); Wed, 22 Aug 2007 09:34:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751422AbXHVNeK (ORCPT ); Wed, 22 Aug 2007 09:34:10 -0400 Received: from mx10.go2.pl ([193.17.41.74]:46453 "EHLO poczta.o2.pl" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750919AbXHVNeJ (ORCPT ); Wed, 22 Aug 2007 09:34:09 -0400 Date: Wed, 22 Aug 2007 15:35:11 +0200 From: Jarek Poplawski To: Andrew Morton Cc: Mariusz Kozlowski , netdev@vger.kernel.org, Jeff Garzik , David Woodhouse , Ingo Molnar , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: [PATCH 2.6.23-rc3-mm1] request_irq fix DEBUG_SHIRQ handling Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state Message-ID: <20070822133511.GH1684@ff.dom.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708100149.14446.m.kozlowski@tuxland.pl> User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2740 Lines: 75 On 10-08-2007 01:49, Mariusz Kozlowski wrote: > Hello, > > ================================= > [ INFO: inconsistent lock state ] > 2.6.23-rc2-mm1 #7 > --------------------------------- > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. > ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes: > (&tp->lock){+...}, at: [] rtl8139_interrupt+0x27/0x46b [8139too] > {in-hardirq-W} state was registered at: > [] __lock_acquire+0x949/0x11ac > [] lock_acquire+0x99/0xb2 > [] _spin_lock+0x35/0x42 > [] rtl8139_interrupt+0x27/0x46b [8139too] > [] handle_IRQ_event+0x28/0x59 > [] handle_level_irq+0xad/0x10b > [] do_IRQ+0x93/0xd0 > [] common_interrupt+0x2e/0x34 ... > other info that might help us debug this: > 1 lock held by ifconfig/5492: > #0: (rtnl_mutex){--..}, at: [] mutex_lock+0x1c/0x1f > > stack backtrace: ... > [] _spin_lock+0x35/0x42 > [] rtl8139_interrupt+0x27/0x46b [8139too] > [] free_irq+0x11b/0x146 > [] rtl8139_close+0x8a/0x14a [8139too] > [] dev_close+0x57/0x74 ... It looks like this was possible after David's fix, which really enabled running of the handler in free_irq, but before Andrew's patch disabling local irqs for this time. So, this bug should be fixed, but IMHO similar problem is possible in request_irq. And, I think, this is not only about lockdep complaining, but real lockup possibility, because any locks in such a handler are taken in another, not expected for them context, and could be vulnerable (especially with softirqs, but probably hardirqs as well). Reported-by: Mariusz Kozlowski Signed-off-by: Jarek Poplawski --- diff -Nurp 2.6.23-rc3-mm1-/kernel/irq/manage.c 2.6.23-rc3-mm1/kernel/irq/manage.c --- 2.6.23-rc3-mm1-/kernel/irq/manage.c 2007-08-22 13:58:58.000000000 +0200 +++ 2.6.23-rc3-mm1/kernel/irq/manage.c 2007-08-22 14:12:21.000000000 +0200 @@ -546,14 +546,11 @@ int request_irq(unsigned int irq, irq_ha * We do this before actually registering it, to make sure that * a 'real' IRQ doesn't run in parallel with our fake */ - if (irqflags & IRQF_DISABLED) { - unsigned long flags; + unsigned long flags; - local_irq_save(flags); - handler(irq, dev_id); - local_irq_restore(flags); - } else - handler(irq, dev_id); + local_irq_save(flags); + handler(irq, dev_id); + local_irq_restore(flags); } #endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/