intr_event_handle never sends EOI if we fail to schedule ithread

Ryan Stone rysto32 at gmail.com
Thu Feb 21 22:15:59 UTC 2013


I recently saw an issue where all interrupts from a particular interrupt
vector were never raised.  After investigating it appears that I ran into
the bug fixed in r239095[1], where an interrupt handler that uses an
ithread was added to the list of interrupt handlers for a particular event
before the ithread was allocated.  If an interrupt for this event
(presumably for a different device sharing the same interrupt line) comes
in after the handler is added to the list but before the ithread has been
allocated we hit the following code:

    if (thread) {
        if (ie->ie_pre_ithread != NULL)
            ie->ie_pre_ithread(ie->ie_source);
    } else {
        if (ie->ie_post_filter != NULL)
            ie->ie_post_filter(ie->ie_source);
    }

    /* Schedule the ithread if needed. */
    if (thread) {
        error = intr_event_schedule_thread(ie);
#ifndef XEN
        KASSERT(error == 0, ("bad stray interrupt"));
#else
        if (error != 0)
            log(LOG_WARNING, "bad stray interrupt");
#endif
    }

thread is true, so we will not run ie_post_filter (which would send the
EOI).  However because the ithread has not been allocated
intr_event_schedule_thread will return an error.  If INVARIANTS is not
defined we skip the KASSERT and return.

Now, r239095 fixes this scenario, but I think that we should call
ie_post_filter whenever intr_event_schedule_thread fails to ensure that we
don't block an interrupt vector indefinitely.  Any comments?

[1] http://svnweb.freebsd.org/base?view=revision&revision=239095


More information about the freebsd-hackers mailing list