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

[Steven Rostedt <rostedt@goodmis.org>]

On Sun, 2006-06-04 at 11:34 +0200, Arjan van de Ven wrote:
> On Sat, 2006-06-03 at 18:34 -0400, Steven Rostedt wrote:
> > On Sat, 2006-06-03 at 17:53 -0400, Alan Cox wrote:
> > > On Sat, Jun 03, 2006 at 10:37:01AM -0400, Steven Rostedt wrote:
> > > > Couldn't it be possible to have the misrouted irq function mark the
> > > > DISABLED_IRQ handlers as IRQ_PENDING?  Then have the enable_irq that
> > > > actually enables the irq to call the handlers with interrupts disabled
> > > > if the IRQ_PENDING is set?
> > > 
> > > We still have the ambiguity with disable_irq. Really we need to have
> > > disable_irq_handler(irq, handler)
> > 
> > Yeah, that does make sense, but I think the IRQ_PENDING idea works too.
> > This way disable_irq_handler doesn't need to mask the interrupt even
> > without the irqpoll and irqfixup.  Let the interrupt happen and just
> > skip those handlers that that are disabled.  Then when the handler is
> > re-enabled, then we can call the handler. Of course we would need a
> > enable_irq_handler too.
> > 
> > This would make the vortex card's disable_irq not hurt all the other
> > devices that share the irq with it.
> can't do that; if you get an irq anyway from the hardware you now have a
> screamer...... which is why vortex really needs to disable the irq at
> the hardware level.
> 

I woke up in the middle of the night last night, thinking about this. I
suddenly realized that this cant work with level interrupts.  Oh well,
if we lived in a world of edge only, then it could work. :-/

But still for the fixirq case, it might still be an option to delay the
handler.

But I'm not sure if I fully understand this misrouting irq.  Is it to
fix broken machines that trigger interrupts on the wrong line?  Or is
this some strange case that happens on normal setups?  If an irq does
get misrouted, and we happen to be in the disable_irq of that device
that had its irq misrouted, couldn't it cause a storm if we don't call
the handler for it?  So really disable_irq is broken for the misrouting
case, and perhaps needs to be replaced with a spin_lock_irqsave?

-- Steve

-- Steve