Hello!
Color me blind, but I don't see how the following race is avoided:
CPU 0: A hardware interrupt is received for a threaded irq, which
eventually results in do_hardirq() being invoked and the
descriptor lock being acquired. Because the IRQ_INPROGRESS
status bit is set, execution continues. Once the handler
returns, having already cleared the IRQ_INPROGRESS status bit,
the descriptor lock is released.
CPU 1: A second hardware interrupt is received for the same threaded
irq, which also wends its way to do_hardirq() with the
IRQ_INPROGRESS status bit set. It enters the handler (having
released the descriptor lock) and accesses some data structure
that CPU 2 now wants to get rid of.
CPU 2: A synchronize_irq() is executed, again for this same irq.
Because the descriptor status does not have the IRQ_NODELAY
bit set, and because the IRQ_INPROGRESS status bit is set,
this task blocks.
CPU 0: Execution continues near the end of do_hardirq(), which notices
that the descriptor wait_for_handler queue is non-empty,
and therefore wakes up CPU 2's task.
CPU 2: The task starts running, and proceeds to clean up the data
structures that CPU 1 is still using.
CPU 1: This second handler is suddenly and fatally disappointed by
the disappearance of its data structures.
So what am I missing here?
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
