Re: Posssible bug in kernel/irq/handle.c

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 9 Nov 2005, Benjamin Herrenschmidt wrote:
> 
> Now, look at what's going on if there is no action, that is desc->action
> is NULL. In that case, the code will go out, leaving the IRQ marked
> IN_PROGRESS, call the end() handler and go out without ever calling
> note_interrupt().

Not a bug afaik.

> That means that
> 
>  1) The interrupt will be stuck IN_PROGRESS. I don't see how IN_PROGRESS
> can ever be cleared afterward

If desc->action is NULL, the flags are supposed to be cleared when we get 
an action. See kernel/irq/manage.c: setup_irq(), and in particular the 
case where we had no handler before (ie the "!shared" case).

>  2) We won't go through the code in note_interrupt() that protects us
> against a stuck interrupt, so if the interrupt is indeed stuck, we'll
> just lockup the processor taking the same IRQ for ever (and not being
> able to handle it, even if an action magically gets registered, due to
> 1)

If the irq is stuck, you have serious problems with your interrupt 
controller. By definition, the irq should be disabled since there are no 
handlers for that interrupt.

So I think the code is correct. It has certainly worked for years on x86 
(and it got serious debugging, since we had some rather nasty and subtle 
issues with edge-triggered APIC interrupts that just get lost if they are 
disabled at the controller).

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/