Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758840AbYKWO1L (ORCPT ); Sun, 23 Nov 2008 09:27:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758180AbYKWO05 (ORCPT ); Sun, 23 Nov 2008 09:26:57 -0500 Received: from casper.infradead.org ([85.118.1.10]:57260 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758179AbYKWO04 (ORCPT ); Sun, 23 Nov 2008 09:26:56 -0500 Subject: Re: [patch 2.6.28-rc2] at91_mci: workaround lockdep From: Peter Zijlstra To: Nicolas Ferre Cc: David Brownell , Pierre Ossman , lkml , Ingo Molnar , Russell King , Nicolas Ferre , Andrew Victor In-Reply-To: <4921394E.2000901@atmel.com> References: <200810271426.27110.david-b@pacbell.net> <4921394E.2000901@atmel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sun, 23 Nov 2008 15:26:35 +0100 Message-Id: <1227450395.7685.20762.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3409 Lines: 76 On Mon, 2008-11-17 at 10:28 +0100, Nicolas Ferre wrote: > David Brownell : > > From: David Brownell > > > > Lockdep reported a problem in the at91_mci driver ... in this case, the > > issue is with lockdep, not with the driver. A trimmed stack dump, from > > trying to boot with root on MMC, shows: > > > > WARNING: at kernel/lockdep.c:2195 trace_hardirqs_on_caller+0xf4/0x170() > > Modules linked in: > > [] (trace_hardirqs_on+0x0/0x18) from [] (_spin_unlock_irq+0x2c/0x3c) > > [] (_spin_unlock_irq+0x0/0x3c) from [] (flush_dcache_page+0x114/0x144) > > [] (flush_dcache_page+0x0/0x144) from [] (at91_mci_irq+0x150/0x414) > > [] (at91_mci_irq+0x0/0x414) from [] (handle_IRQ_event+0x2c/0x6c) > > [] (handle_IRQ_event+0x0/0x6c) from [] (handle_level_irq+0x108/0x124) > > [] (handle_level_irq+0x0/0x124) from [] (__exception_text_start+0x64/0x90) > > > > When __flush_dcache_aliases() returns -- inlined into flush_dcache_page(), > > above -- it re-enables IRQs ... since that evidently may only be called with > > IRQs enabled. That's OK since the (unshared) IRQ handler doesn't ask for IRQs > > to be disabled. Except ... that lockdep went and disabled them, then went on > > to complains about the breakage *it* caused! > > > > Workaround: depend on LOCKDEP=n ... and for paranoia, disable IRQF_SHARED > > for this interrupt. (At the hardware level, this is dedicated to MCI, so > > there's never a need for multiple handlers.) > > > > Signed-off-by: David Brownell > > Acked-by: Nicolas Ferre Nacked-by: Peter Zijlstra > > > --- > > An alternate fix might be to have ARM dcache mmap locking save and restore > > the IRQ flags ... but there are several such "can't run with IRQs disabled" > > restrictions scattered through that code, with no rationales commented. Or > > stop lockdep from mucking with IRQ flags; probably not any time soon! > > > > So for now, this seems to be the best "solution" available... > > > > drivers/mmc/host/Kconfig | 1 + > > drivers/mmc/host/at91_mci.c | 3 +-- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > --- a/drivers/mmc/host/Kconfig > > +++ b/drivers/mmc/host/Kconfig > > @@ -99,6 +99,7 @@ config MMC_AU1X > > config MMC_AT91 > > tristate "AT91 SD/MMC Card Interface support" > > depends on ARCH_AT91 > > + depends on LOCKDEP=n > > help > > This selects the AT91 MCI controller. > > > > --- a/drivers/mmc/host/at91_mci.c > > +++ b/drivers/mmc/host/at91_mci.c > > @@ -1081,8 +1081,7 @@ static int __init at91_mci_probe(struct > > * Allocate the MCI interrupt > > */ > > host->irq = platform_get_irq(pdev, 0); > > - ret = request_irq(host->irq, at91_mci_irq, IRQF_SHARED, > > - mmc_hostname(mmc), host); > > + ret = request_irq(host->irq, at91_mci_irq, 0, mmc_hostname(mmc), host); > > if (ret) { > > dev_dbg(&pdev->dev, "request MCI interrupt failed\n"); > > goto fail0; > > > > Thanks, regards, -- 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/