Re: [patch, -rc5-mm1] locking validator: special rule: 8390.c disable_irq()

[Ingo Molnar <mingo@elte.hu>]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Sun, 2006-06-04 at 22:26 +0100, Alan Cox wrote:
> > Ar Sul, 2006-06-04 am 12:22 -0400, ysgrifennodd Steven Rostedt:
> > > But can't this machine still cause an interrupt storm if the interrupt
> > > comes on a wrong line, and we don't call the handler for the interrupt
> > > source because we are now honoring disable_irq?
> > 
> > Yes - that is why we can't honour disable_irq in this case but have to
> > hope 8)
> > 
> 
> Hmm, maybe this can be solved with something like what the -rt patch 
> does with threading interrupts and the interrupt mask.  I'm not 
> suggesting threading interrupts.  But, if the misrouted irq comes 
> across a disabled_irq, that it sets some flag, and doesn't unmask the 
> interrupt when finished.  Have enable_irq see the flag and have it 
> unmask the interrupt if it is safe to do so.
> 
> This all may be pretty hacky, but it's trying to fix code for hardware 
> that is already hacky.  Note, that this would need to be compiled in 
> as on option to actually implement any of this crap.

no ... lets not mix threaded IRQs in here. The model of executing an 
interrupt handler has nothing to do with the irq flow itself. Whatever 
can be done with a threaded handler can be done via atomic ISRs too.

pretty much the only correct solution seems to be to go with Arjan's 
suggestion and make the 'disabled' property per-action, instead of the 
current per-desc thing. (obviously the physical act of masking an 
interrupt line is fundamentally per-desc, but the act of running an 
action "behind the back" of a masked line is still OK.) Unfortunately 
this would also mean the manual conversion of 300+ places that use 
disable_irq()/enable_irq() currently ... so it's no small work. (and the 
hardest part of the work is to find a safe method to convert them 
without introducing bugs)

	Ingo