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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
