Re: [RFC][PATCH] irq: remove IRQF_DISABLED

Bartlomiej Zolnierkiewicz
2009-03-02T18:49:16Z

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