RE: Race condition in interrupt handling

This seems fishy to me. intctrl_t::unmask() should only be called by irq_thread, which resides on the CPU the IRQ is routed to. Since it is in the kernel, how can the new IRQ be delivered to the CPU at the point you're referring to with (1) INTERRUPT COMES HERE? Again, does this happen during IRQ migration? Maybe you can use the tracebuffer (potentially even inserting some tracing statements at the critical points yourself, e.g. via TRACE_IRQ_DETAILS() and tp_irq_mask, latter of which you can set in the KDB menu, in the tracebuffer submenu "y") and dump a corresponding trace log to this list?

Thanks again,
-Jan

--
Jan Stoess
KIT/UKa System Architecture Group
Phone: +49 (721) 608-4056
Fax: +49 (721) 608-7664
http://os.ibds.kit.edu/stoess