linux-kernel - Re: [RFC][PATCH] irq: remove IRQF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0903021012080.3111@localhost.localdomain>
Date:	Mon, 2 Mar 2009 10:29:12 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC][PATCH] irq: remove IRQF_DISABLED

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/