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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
