lkml.org 
[lkml]   [2005]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.042 / U:0.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site