Messages in this thread | | | Date | Tue, 8 Nov 2005 17:04:46 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Posssible bug in kernel/irq/handle.c |
| |
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/
| |