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: <200903021948.51500.bzolnier@gmail.com>
Date:	Mon, 2 Mar 2009 19:48:51 +0100
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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 Monday 02 March 2009, Linus Torvalds wrote:
> 
> 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 

Hmm, I said nothing about how it is implemented in the IDE code itself. :)

> 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.

Fixing this is on long-term TODO (there was just a ton of more high-prio
stuff to take care of first).

Thanks,
Bart
--
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/