Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758014AbZCBSaZ (ORCPT ); Mon, 2 Mar 2009 13:30:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751809AbZCBSaJ (ORCPT ); Mon, 2 Mar 2009 13:30:09 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:46234 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751692AbZCBSaI (ORCPT ); Mon, 2 Mar 2009 13:30:08 -0500 Date: Mon, 2 Mar 2009 10:29:12 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Bartlomiej Zolnierkiewicz cc: Peter Zijlstra , Ingo Molnar , Thomas Gleixner , lkml , linux-arch , Andrew Morton Subject: Re: [RFC][PATCH] irq: remove IRQF_DISABLED In-Reply-To: <200903021855.02765.bzolnier@gmail.com> Message-ID: References: <1235996477.5330.174.camel@laptop> <200903021855.02765.bzolnier@gmail.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2365 Lines: 59 On Mon, 2 Mar 2009, Bartlomiej Zolnierkiewicz wrote: > > > > Could we make just the IDE driver itself enable interrupts? Sure. But that > > Actually it has been doing it for years (some host drivers don't do this by > default and still need "hdparm -u" or equivalent but I was planning to change > it for 2.6.30). The IDE layer has the option to enable irq's during the transfer itself, yes. But it actually works the reverse way from what you think: the irq layer will enable interrupts, and the IDE layer will then _not_ disable them during the transfer if you use "hdparm -u". Look at ide_intr: it generally gets called with interrupts _enabled_ (because it doesn't use IRQF_DISABLED) and then it does: spin_lock_irqsave(&hwif->lock, flags); .. spin_unlock(&hwif->lock); .. if (drive->dev_flags & IDE_DFLAG_UNMASK) local_irq_enable_in_hardirq(); ... spin_lock_irq(&hwif->lock); ... spin_unlock_irqrestore(&hwif->lock, flags); where the magic thing is how it enables irqs again if the "irq unmask" flag is set. The point I'm making is that - as far as the generic irq layer is concerned, IDE might as well have interrupts enabled all the time (and disabling them is a local issue, more to do with locking and with timing-induced hardware _bugs_ rather than anything else) - .. and more importantly, that is AS IT MUST BE. Because quite frankly, if the irq handler enables interrupts (like IDE does), the generic IRQ layer really _must_ know about it, because it may depend on non-reentrancy of that interrupt. (Small detail: the current irq layer actually does have that "IRQ_INPROGRESS" flag to handle re-entrancy issues regardless of anything else, so I guess we technically are robust in this regard. But that's partly an SMP issue, and conceptually it's still really really important information to know whether interrupts can nest. In practice, it does affect things like stack usage too, for example, so even with IRQ_INPROGRESS, there really is a difference between IRQF_DISABLED and not having it on). Linus -- 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/